mcp-repo-graph
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REPO_GRAPH_REPO | No | The path to the repository to analyze |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| orientA | Get the lay of the land — ALWAYS the first call on a codebase. With no arguments: a counts + entry-points overview plus a |
| findA | Turn any text into the ranked nodes that matter — the on-ramp to the graph. A symbol or keyword returns matching nodes; a pasted stacktrace / failing-test id / diff is resolved to the code it implicates and ranked by relevance. Set |
| impactA | Blast radius in one call: fan out from one or more nodes to everything they affect (forward) or depend on / are used by (backward), returned as a deduped, ranked, located closure. Ranking is co-change first where the repo has git history synced, then Personalized PageRank. Each row carries |
| traceA | Follow the code across boundaries. One argument: trace a feature end-to-end — the ordered path from entry through the stack, each hop labelled with its mechanism (call / HTTP / queue / event / data), crossing service boundaries (frontend→backend). Two arguments: the shortest path between two specific nodes, hop by hop. This is where the graph beats reading many files — it knows the cross-stack links grep can't see. |
| readA | Return the source code for one or more nodes, sliced from their files by the graph's line spans. Use after |
| refreshA | (Re)build the structural graph with tree-sitter AST parsing across 20 languages, running the cross-stack resolvers (HTTP, gRPC, GraphQL, WebSocket, queues, events, CLI). Incremental by default — only changed files re-parse — so it's cheap to call after edits; set |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool maps to a distinct operation: orient (overview/map), find (text→nodes), impact (ranked fan-out), read (source retrieval), trace (path following), refresh (build). The main blurred boundary is between `find` with `expand=true` and `impact`, and between `orient seed=` and `impact` depth-1 — both fan out over the neighborhood, and only the descriptions disambiguate them.
All six tools use short, lowercase, single-verb names with no prefixes or mixed conventions (impact, find, orient, read, refresh, trace). The pattern is predictable and readable throughout.
Six tools is tightly scoped for a code-graph engine, and each one covers a genuinely different phase of the workflow (orient → find → read/impact/trace, with refresh for maintenance). No tool feels redundant or missing from the count perspective.
The surface covers the full read-only analysis lifecycle: map the repo, locate nodes, read source, measure blast radius, trace cross-stack flows, and rebuild the graph incrementally. Minor gaps exist — no explicit node/edge inspection or metadata/stats query beyond orient's overview, and no diff-scoped entry point apart from passing multiple nodes to impact.