Skip to content

bug(cli/mcp): add_code_to_graph declares a graph_name input but the handler ignores it — repos silently land in the default graph #1558

Description

@Shashankss1205

tool_definitions.py:25 declares graph_name as an input to add_code_to_graph:

"graph_name": _GRAPH_NAME_PROP

but the handler never reads it — tools/handlers/indexing_handlers.py:12-21:

def add_code_to_graph(graph_builder, job_manager, loop, list_repos_func, **args) -> Dict[str, Any]:
    path = args.get("path") or args.get("repo_path")
    is_dependency = args.get("is_dependency", False)
    ...

Only path, repo_path and is_dependency are consulted. graph_name is silently discarded.

Impact

FalkorDB is the default backend and is multi-graph — list_graphs is an exposed tool (tool_definitions.py:386) and query handlers honour graph_name (handlers/query_handlers.py:46). So an agent can legitimately do:

add_code_to_graph(path="/repos/service-a", graph_name="service-a")

and reasonably believe the repository landed in service-a. It lands in the default graph instead, with no warning. A later analyze_code_relationships(..., graph_name="service-a") then finds nothing, and the failure looks like "indexing didn't work" rather than "the argument was ignored".

This is the write-side counterpart to #1531, where graph_name is accepted but clobbered for two query types.

Related, same shape

api/router.py:99-101 discards branch, repo_name and force from IndexRequest:

args = {"path": request.path}   # repo_name/branch/force are not supported

IndexRequest.branch is declared at api/schemas.py:8, so the HTTP API advertises a field it drops. (Relevant to #736, which asks for per-branch indexes.)

Suggested fix

Either honour graph_name in the handler by routing the writer to db_manager.get_driver(graph_name), or remove it from the tool schema until it is implemented. Advertising an argument that is silently ignored is worse than not offering it — the same applies to the three discarded IndexRequest fields.


Environment
Commit HEAD (0.5.4)
Python 3.12.3, Linux

Found during backlog triage while verifying #736. Verified by reading the schema against the handler.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: cli/mcpCLI commands, MCP tool contracts, docsbugSomething isn't workingseverity: mediumIncorrect results, misleading output, or a broken contract

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions