MCP server: silent wrong matches on ambiguous/near-miss names, noisy query_graph, misleading list_prs error

[Alexandre-Aktisea]

Version: graphifyy 0.9.71 (installed via uv tool), graphify-mcp over stdio, started with an explicit graph.json path.
Codebase: PHP / Symfony bundle, ~11k nodes / ~33k edges, 614 communities.

1. get_node silently picks one match for an ambiguous name

• Steps: get_node(label="edit") on a graph where several classes define edit().
• Actual: returns a single node (Controller/VisitController.php L427) with no hint that other candidates exist.
• Expected: a list of the candidates (path + line), or an explicit "ambiguous, N matches" error. The caller can't tell whether the answer is the right edit().

2. get_node silently resolves a non-existent name to a different node

• Steps: get_node(label="MailController") when no MailController exists in the codebase.
• Actual: returns EmailController as if it were an exact match.
• Expected: "no exact match", optionally followed by fuzzy suggestions clearly labelled as such.

Side note: the path::symbol form works (Controller/VisitController.php::edit → found). get_node(node_id=...) does not find a generated-looking id for a non-existent symbol, which is correct.

3. query_graph is dominated by god nodes

• Steps: query_graph(question="who sends the convocation emails?"), default depth 3.
• Actual: BFS starts from 5 seeds and reaches 2,708 nodes. The output is TRUNCATED and mostly made of the highest-degree nodes (framework interfaces, core entities, enums). With token_budget=8000 it is still truncated (240 of 2,708). With context_filter=['call'] only 20 nodes remain, all unrelated test helpers.
• Expected: rank results by relevance or distance to the seeds rather than degree, or damp hubs during traversal (similar to exclude_hubs_percentile in god_nodes).

4. get_community returns no community label

get_community(3) returns "Community 3 (205 nodes)" with no name or summary. A generated label (e.g. dominant class or directory) would make the output usable.

5. list_prs reports "gh CLI not found" when the real issue is repo detection

• Steps: list_prs() with no repo argument, the server started on a graph.json outside any git repo.
• Actual: Error: gh CLI not found or not authenticated. Run: gh auth login. gh is installed and authenticated. Passing repo=owner/name makes it work. get_pr_impact with the same repo works too.
• Expected: an error such as "could not detect repository; pass repo=".

6. Minor: get_neighbors truncation hides incoming edges

With the default budget, outgoing edges are listed first, so all incoming edges (callers) are cut off on high-degree nodes. Listing incoming edges first, or balancing both directions, would help.

[github-actions]

Thanks for opening this issue, @Alexandre-Aktisea. A maintainer will take a look soon.

If you would like to discuss it in real time, come say hi on our Discord server. For longer-form questions and ideas there is also GitHub Discussions.

To help us triage, please make sure the report includes what you expected, what actually happened, and the steps (and a small sample) to reproduce it.