Skip to main content
Glama
Srinivasan-78

repo2graph

by Srinivasan-78
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

repo_neighbours

Idempotent

Traverse code graph relationships from a known symbol or file node_id (callers, callees, base classes, definitions). Read-only, deterministic traversal, no side effects. When to use: use with a specific node_id (e.g.

Instructions

Traverse code graph relationships from a known symbol or file node_id (callers, callees, base classes, definitions). Read-only, deterministic traversal, no side effects. When to use: use with a specific node_id (e.g. from repo_search citations) to inspect callers (CALLS in), callees (CALLS out), inheritance, definitions, or the tests that reach a symbol through calls (TESTS in). When NOT to use: do not use for text search across code (use repo_search) or repo overview (use repo_map). Output: markdown list formatted as - <EDGE_TYPE> <in|out>: <name> (<path:line>) [<node_id>], or with format="json" the same rows as JSON plus co-changed files. To page past limit, pass cursor="" then each next_cursor: token from the reply's last line.

Input Schema

NameRequiredDescriptionDefault
hopsNoTraversal depth from node_id (default 1, max 4).
limitNoMaximum neighbor rows to return (default 20, min 1, max 50).
cursorNoOpt-in paging. Omit for one unpaged answer. Pass "" for the first page of limit rows; while more remain the reply ends with a `next_cursor: <token>` line (also _meta.nextCursor). Pass that token back, other arguments unchanged, for the next page.
formatNoOutput format (default markdown). json returns {node, neighbours, cochange, truncated}: each neighbour row with its edge, direction, path and lines, and the files co-edited with the node's file -- for programs such as editors.
node_idYesTarget graph node identifier to expand from (e.g. 'sym:pkg/mod.py::func', 'file:pkg/mod.py', 'dir:pkg').
min_confidenceNoDrop CALLS and TESTS edges below this confidence, 0..1 (default 0.0: keep everything, marking ambiguous edges). 1.0 keeps only unambiguous ones.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.0.0
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Opt-in paging. Omit for one unpaged answer. Pass \"\" for the first page of limit rows; while more remain the reply ends with a `next_cursor: <token>` line (also _meta.nextCursor). Pass that token back, other arguments unchanged, for the next page.",
+  "type": "string"
+}
    • addedInput schema / properties / format
      Added value: +{
+  "description": "Output format (default markdown). json returns {node, neighbours, cochange, truncated}: each neighbour row with its edge, direction, path and lines, and the files co-edited with the node's file -- for programs such as editors.",
+  "enum": [
+    "markdown",
+    "json"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / min_confidence
      Added value: +{
+  "description": "Drop CALLS and TESTS edges below this confidence, 0..1 (default 0.0: keep everything, marking ambiguous edges). 1.0 keeps only unambiguous ones.",
+  "type": "number"
+}
  2. Changed1 schema field changedv3.0.0
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum neighbor rows to return (default 20, max 50)."New value: +"Maximum neighbor rows to return (default 20, min 1, max 50)."
  3. Changed3 schema fields changedv1.5.1
    • changedInput schema / properties / hops / description
      Previous value: -"graph hops (default 1, max 4)"New value: +"Traversal depth from node_id (default 1, max 4)."
    • changedInput schema / properties / limit / description
      Previous value: -"neighbours (default 20, max 50)"New value: +"Maximum neighbor rows to return (default 20, max 50)."
    • changedInput schema / properties / node_id / description
      Previous value: -"e.g. sym:pkg/a.py::run"New value: +"Target graph node identifier to expand from (e.g. 'sym:pkg/mod.py::func', 'file:pkg/mod.py', 'dir:pkg')."
  4. First observedv0.1.0

TDQS

A3.8/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description asserts 'Read-only, deterministic traversal, no side effects', but the annotations declare readOnlyHint=false, which tells the agent this tool may modify state. That is a direct conflict on the single most important behavioral attribute, and the calibration rubric scores a description that contradicts its annotations as 1 regardless of other detail. The otherwise useful extras (deterministic ordering, paging protocol) cannot offset a contradiction about mutability.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense but front-loaded: purpose, then use/not-use, then output and paging. Every clause carries information, though the final sentence on cursor handling is long enough to be slightly cumbersome and partially duplicates the cursor schema description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter read-style traversal with no output schema, the description covers edge types, direction notation, the exact markdown row format, the json alternative including co-change data, and the paging continuation token. An agent has everything needed to call and interpret it, aside from the mutability inconsistency noted above.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so hops, limit, node_id, format and min_confidence semantics are already documented in the schema; baseline is 3. The description adds only marginal value beyond that: the cursor paging handshake and the json payload shape (neighbours plus co-changed files), with no extra detail on hops or min_confidence thresholds.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('traverse code graph relationships from a known symbol or file node_id') and enumerates the edge kinds traversed (callers, callees, base classes, definitions, TESTS). It explicitly distinguishes itself from the siblings repo_search and repo_map, so an agent can pick it without opening sibling schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Contains explicit 'When to use' and 'When NOT to use' sections that name the alternatives (repo_search for text search, repo_map for overview) and the triggering input (a node_id from repo_search citations). Routing is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools