Provides a graph-based codebase analysis using Neo4j, allowing agents to query code relationships such as callers, dependencies, and impact of changes.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@repo-atlas-mcp find the impact of changing the 'send_email' function"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives coding agents a graph of your codebase instead of a text search over it.
Grep finds a name. It cannot tell you who calls that function, what breaks if you change it, or whether
any test reaches it. Those are relationship questions, so repo-atlas-mcp parses your repository with
tree-sitter, loads the call and import structure into Neo4j, and exposes it to your agent as MCP tools.
▸ hotspots
17 callers stock_analyzer/base.py:54 is_num
10 callers stock_analyzer/data/market.py:144 get_row
9 callers stock_analyzer/base.py:12 Finding
▸ impact_of is_num
21 production caller(s) across 11 file(s).
⚠ No test reaches this symbol on any call path — changes here are unguarded.Reachability is transitive, and transitive questions are exactly what a graph database answers in one
query and a text search cannot answer at all. impact_of walks every call path upstream of a symbol,
partitions the callers into production code and tests, and tells you when nothing guards the change.
That is the query that stops an agent from confidently editing shared code.
Related MCP server: Axon Pro
Node.js 18+
A Neo4j instance. AuraDB Free is enough for repositories in the hundreds-of-thousands-of-lines range and costs nothing.
Create a free AuraDB instance, then note the connection URI and password it gives you.
Add the server to your MCP client:
{
"mcpServers": {
"repo-atlas": {
"command": "npx",
"args": ["-y", "repo-atlas-mcp"],
"env": {
"NEO4J_URI": "neo4j+s://xxxxxxxx.databases.neo4j.io",
"NEO4J_USER": "neo4j",
"NEO4J_PASSWORD": "your-password"
}
}
}
}For Claude Code that goes in .mcp.json at your project root, or run:
claude mcp add repo-atlas -- npx -y repo-atlas-mcpThen ask your agent to index the project once:
index this repo at /path/to/project
Re-indexing is incremental — unchanged files are skipped by content hash, so running it again after a few edits takes about as long as parsing the files you touched.
Tool | Question it answers |
| Build or refresh the graph for a repository |
| Where is this function/class/method defined? |
| What reaches this symbol, transitively? |
| What does this symbol depend on, transitively? |
| What breaks if I change this — and do any tests cover it? |
| How does control flow from A to B? |
| Which symbols have the most distinct callers? |
| What does the top-level package structure depend on? |
| What is indexed? |
| Remove a repository from the graph |
Python, TypeScript, TSX, and JavaScript, via tree-sitter WASM grammars — no native compilation, so
npx works on a clean machine without build tools.
Resolving a call to a definition properly requires full type inference. This does something cheaper and tells you when it is guessing. What the call looks like decides how it is resolved:
self.foo() / this.foo() — resolves to foo on the enclosing class, else to a definition in the
same file. This is the one method form that resolves precisely. Tier: local.
foo() — a bare call, very likely a repo-level function. Resolved against a definition in the same
file (local), then in a file this one imports (imported), then repo-wide if three or fewer
candidates exist (global).
something.foo() — the receiver's type is unknown. Accepted only when foo is defined exactly once
in the whole repository and is not a well-known builtin name. Tier: receiver.
That last rule matters more than it looks. Without it, one repo method named get absorbs every
dict.get() and response.get() in the codebase; on a real 26-file project it produced a phantom
symbol with 59 callers, ranked as the most-called code in the project. The denylist in
COMMON_METHOD_NAMES (get, add, update, join, map, read, …) is a heuristic, and it is
consulted only for this weakest case — a bare get() still resolves normally.
Every CALLS edge stores which tier produced it, and the tools surface anything above local.
Known limitations, stated plainly:
Dynamic dispatch is invisible. getattr(obj, name)(), reflection, and dependency-injection
wiring produce no edges.
Polymorphism is not modelled. Two classes with a run() method cannot be told apart, so calls on
a non-self receiver to a name defined more than once are dropped rather than guessed.
Calls into third-party packages are dropped. Only symbols defined inside the repository become nodes.
Top-level code is attributed to a synthetic <module> symbol per file, so route registration and
CLI wiring still appear in the graph rather than being discarded.
Repeated calls between the same pair collapse to one edge, which keeps the last line number seen.
The practical effect: the graph under-reports rather than over-reports. impact_of can miss a caller
that goes through dynamic dispatch, so treat its output as a strong lead, not a proof — but a symbol it
names really is a caller.
(:Repo)-[:HAS_FILE]->(:File)-[:DEFINES]->(:Symbol)
(:File)-[:IMPORTS]->(:File)
(:Symbol)-[:CALLS {line, confidence}]->(:Symbol)Symbol.isTest is set from the defining file's path, which is what lets impact_of separate covering
tests from production callers.
Ranking in hotspots uses caller in-degree rather than PageRank, so it runs on AuraDB Free, which does
not include the Graph Data Science library.
npm install
npm run build
node scripts/smoke.mjs # parser check, no database needed
node scripts/bulk-parse.mjs /some/repo # parse a real repo and report totalsMIT
Delete every node belonging to a repository. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It does state the operation is 'Irreversible' and that it deletes 'every node', which are key traits. However, it omits other relevant behaviors such as permission requirements, potential side effects on other repositories, and error behavior, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the action and add the crucial irreversibility warning. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool with no output schema and no annotations. The description covers the core action and irreversibility, but it does not address potential return values, success/failure reporting, or what happens to related data, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. The description implies the 'repo' parameter identifies a repository but does not specify the expected format (e.g., name, ID, path) or any constraints beyond the schema's type string. This leaves the parameter semantics underdefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('every node belonging to a repository'), which aligns with the title 'Remove a repository from the graph'. This distinguishes it from sibling tools like list_repos and index_repo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. The only hint is 'Irreversible', which is a warning but not a usage guideline. No prerequisites, exclusions, or comparison with sibling tools are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate the definition of a function, class or method by name. Accepts a bare name (fetch_info) or a qualified one (MarketData.fetch_info), and falls back to substring matching.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| name | Yes | Symbol name to look up | |
| repo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It discloses matching semantics (bare/qualified names, substring fallback) but does not mention other important traits such as case sensitivity, behavior on multiple matches, or whether the repo parameter is required for scoping. The provided behavior is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the primary purpose. Every sentence adds value: the first states the core function, the second explains input flexibility and fallback behavior. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema or annotations. The description adequately covers the name parameter and overall purpose, but it lacks explanation of the repo parameter and expected return value or error behavior. It is not a complex tool, but the gaps in parameter and output information make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'name' is described). The description adds meaningful semantics for 'name' (bare/qualified, substring matching) but says nothing about 'kind' or 'repo'. Since coverage is low, the description should compensate fully, but it only partially does so, leaving two of three parameters unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Locate the definition of a function, class or method by name.' It specifies a concrete verb and resource, and the scope (by name) distinguishes it from siblings like who_calls and what_it_calls, which focus on call relationships rather than definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context on accepted name formats ('bare name' or 'qualified one') and fallback behavior ('substring matching'), which implies when to use it. However, it does not explicitly state when to prefer this tool over siblings or provide exclusions, so guidance is more implied than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Symbols with the most distinct callers — the code where a mistake propagates furthest. Ranked by in-degree, which works on Neo4j AuraDB Free (no GDS required).
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that results are 'ranked by in-degree' and explicitly notes compatibility ('works on Neo4j AuraDB Free, no GDS required'), which is useful technical context. However, it does not mention whether the operation is read-only, any side effects, or the exact return format, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and includes only valuable additional context (ranking method and compatibility). Every word earns its place — no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only ranking tool with two parameters and no output schema, the description is adequate but incomplete. It tells the agent what is returned (ranked list of symbols) but omits parameter semantics and any caveats about repositories or limits. Given the zero-coverage schema, a bit more detail would make it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'repo' or 'limit' parameters. The tool's purpose implies 'repo' is the repository to analyze and 'limit' caps results, but the agent is left to infer this without any guidance on defaults, format, or role. The description completely fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it identifies 'symbols with the most distinct callers' and ranks them. The phrase 'the code where a mistake propagates furthest' adds intent. This distinguishes it from siblings like who_calls (which traces callers of a specific symbol) and impact_of (which likely analyzes a given symbol's impact).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to find high-risk code where mistakes have broad reach. It does not explicitly name alternatives or give 'when not to use' instructions, but the use case is implicit and distinct from sibling tools that focus on individual symbols or paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What breaks if this symbol changes. Returns everything transitively upstream, split into production callers and the tests that reach it. An empty test list means the change is unguarded — check this before editing shared code.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| depth | No | Call hops to follow (default 4) | |
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool returns transitive upstream callers, separates production callers from tests, and treats an empty test list as a signal that the change is unguarded. This goes beyond a generic 'impact analysis' phrase, though it doesn't discuss parameters, output format details, or potential performance costs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every clause adds value. The warning about empty test lists and the 'check before editing shared code' guidance are compact and actionable without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and sparse parameter docs, the description covers the essential output structure (production callers vs tests) and provides interpretation guidance (empty test list = unguarded). It leaves minor gaps around symbol formatting and depth semantics, but the schema covers depth, and the core use case is well specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% because only 'depth' has a description. The tool description does not explain the meaning of 'symbol' (e.g., whether it needs a fully qualified name) or 'repo' (e.g., optional or default repository). Since coverage is low, the description should compensate, but it only refers generically to 'this symbol.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the direct question 'What breaks if this symbol changes' and clearly states the resource (a symbol) and the specific output (everything transitively upstream, split into production callers and tests). It distinguishes this from sibling query tools like who_calls or what_it_calls by emphasizing transitive upstream impact and testing coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'check this before editing shared code.' It implies this tool is for pre-edit impact assessment and even signals when to be cautious (empty test list means unguarded change). It doesn't explicitly contrast with siblings, but the 'before editing shared code' instruction provides a practical trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a repository and build its code graph in Neo4j. Run this once per project, and again after significant changes — unchanged files are skipped by content hash, so re-indexing is cheap. Supports Python, TypeScript, TSX and JavaScript.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the repository root | |
| repo | No | Identifier for this repo; defaults to the directory name | |
| force | No | Re-parse and rewrite every file, ignoring content hashes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds meaningful behavioral details: it skips unchanged files via content hash, supports specific languages, and persists to Neo4j. However, it does not disclose whether re-indexing replaces or merges existing graph data, whether Neo4j needs to be running, or any prerequisites. For a mutation tool, these are notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, then usage and supported languages. Every sentence serves a purpose with no filler. It is appropriately sized for the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (builds a code graph, has re-indexing behavior), and there is no output schema or annotations. The description covers the main action and re-indexing but omits operational details like whether existing graph data is updated or destroyed, whether Neo4j must be pre-configured, and what the tool returns. These are meaningful gaps for an AI agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantic value beyond the schema by explaining the content-hash skipping behavior, which gives context to the 'force' parameter (re-parse ignoring hashes). It also frames the 'repo' identifier through 'Run this once per project,' even though the schema already explains defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Parse a repository and build its code graph in Neo4j.' It uses a specific verb ('build') and resource ('code graph in Neo4j'), and distinguishes itself from sibling tools that are all query/analysis tools (e.g., find_symbol, hotspots) by being the indexing/setup step. Supported languages are also listed, adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit timing guidance: 'Run this once per project, and again after significant changes.' It also explains the cost benefit ('unchanged files are skipped by content hash, so re-indexing is cheap'). While it doesn't explicitly mention when not to use it or alternatives, the context of sibling tools implies this is for initial setup, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which repositories are in the graph, and how many files each has.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does convey that this is a read-only enumeration ('Which repositories are in the graph') and the returned information, but it does not mention sorting, pagination, or clarify the term 'graph'. It is minimally transparent but not richly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds meaning: 'Which repositories', 'in the graph', and 'how many files each has' together convey the purpose and output efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description adequately covers the output shape (repositories and file counts). However, since there is no output schema and no annotations, a slightly more explicit return structure or a note that it is read-only would make it more complete. It is nearly sufficient but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline score is 4. There are no parameter semantics for the description to explain, and the schema coverage is trivially complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'List indexed repositories' supplies the verb, and the description specifies exactly what is returned: which repositories are in the graph and their file counts. This clearly distinguishes it from sibling tools like path_between, index_repo, and drop_repo, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what is listed, without any when-to-use or when-not-to-use context, so an agent has no explicit help choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import edges aggregated to top-level directories — a quick read on the architecture and on which packages depend on which.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read operation ('quick read') but does not describe the output format, whether it is safe or has side effects, or any constraints like repository requirements or limit behavior. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. It has no filler, but it is under-specified, so it could be more informative. However, for the information it does provide, it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is too minimal. It does not clarify what the return data looks like, how the 'limit' parameter affects results, or what happens when `repo` is omitted (since no params are required). The tool's complexity is low, but the absence of critical behavioral and parameter details makes the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. The `repo` string and `limit` integer are not described at all, and with no parameter details in the schema, the agent cannot infer their role or defaults. The description does not compensate for the schema's silence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: aggregates import edges to top-level directories, and gives the purpose of providing a quick architectural read. This differentiates it from sibling tools like who_calls or path_between by focusing on top-level aggregation rather than detailed relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'quick read on the architecture' implies use when an overview is needed, but it does not explicitly mention when not to use it or name alternatives. There is no explicit guidance on choosing this over sibling tools, so the usage context is only mildly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How control actually flows from one symbol to another — e.g. from an HTTP handler to a database write.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| repo | No | ||
| maxDepth | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavior. It explains that the tool shows how control flows, implying a read-only traversal, but it does not describe what the output looks like, how errors (e.g., no path found) are handled, or any side effects. The extra wording beyond the title adds only a modest conceptual clarification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-crafted sentence that immediately conveys the core purpose. It is front-loaded with the main idea and the example adds value without unnecessary length. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, 0% schema coverage), the description is insufficiently complete. It lacks parameter semantics, return value information, and explicit usage conditions. The example helps but does not compensate for the missing critical details needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, and the description does not explain any of the four parameters (from, to, repo, maxDepth). It fails to indicate that 'from' and 'to' are symbols or how 'maxDepth' affects the search. The description entirely omits parameter semantics, which is critical given the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool finds the shortest call path between two symbols, distinguishing it from sibling tools like who_calls and what_it_calls. The example 'from an HTTP handler to a database write' concretely illustrates the purpose and adds specificity beyond the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the example but does not explicitly state when to prefer this tool over alternatives like who_calls or what_it_calls, nor does it mention any exclusions or prerequisites. The example provides context, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything this symbol calls, transitively — the downstream surface of a function.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| depth | No | ||
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose the key behavior of transitive traversal ('everything this symbol calls, transitively'), but omits details about depth limits, cycle handling, result granularity, or any side effects, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and the dash-separated metaphor adds clarity without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no annotations, and no output schema, the description is too sparse. It fails to explain the semantics of repo and depth, the return format, or how it relates to sibling graph-query tools, which is necessary for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not compensate by explaining the three parameters. It only implicitly references 'symbol' via the title, and says nothing about what 'repo' and 'depth' mean or how they affect the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly identify the action (find callees) and the resource (a symbol). The phrase 'Everything this symbol calls, transitively' precisely conveys the downstream traversal, distinguishing it from sibling tools like who_calls which find callers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—exploring the downstream surface of a function—but provides no explicit guidance on when to prefer this over who_calls or impact_of, nor any exclusions or conditions. The context is clear but not formalized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every symbol that reaches this one through the call graph, nearest first. This is the question grep answers badly: it finds the name, not the callers.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| depth | No | How many call hops to follow (default 1) | |
| symbol | Yes | Symbol name, bare or qualified |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure and does a good job by explaining that the tool returns every symbol that reaches the target through the call graph, with nearest-first ordering. It does not disclose output format or performance limitations, but the core traversal behavior is clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the first states the core behavior, and the second provides a useful analogy to grep. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the main purpose and ordering but omits any detail about the return payload, the repo parameter, or prerequisites like indexing. Given the lack of an output schema and annotations, a bit more detail would be helpful, though the tool's simplicity keeps it at an adequate level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the parameters (repo, depth, symbol). The schema already describes symbol and depth, but repo has no description, and the tool description does not clarify its role or how depth affects the results, so it fails to supplement the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: it finds all symbols that reach the given one through the call graph, ordered by distance. It also distinguishes itself from grep and implicitly from sibling tools like what_it_calls (callees) by emphasizing it finds callers, not the symbol definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for call-graph analysis but never explicitly states when to prefer this tool over siblings or when not to use it. It only contrasts with grep, not with other tools like find_symbol or impact_of, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0drop_repofind_symbolhotspotsimpact_ofindex_repolist_reposmodule_mappath_betweenwhat_it_callswho_callsScored across 10 tools
Tools like who_calls, impact_of, and hotspots all concern callers of a symbol, which could cause an agent to pick the wrong one. However, their descriptions clarify distinctions (nearest callers vs. full upstream impact vs. ranked by caller count), reducing ambiguity.
Names are all snake_case and readable, but they mix verb_noun patterns (list_repos, index_repo, find_symbol) with question-style phrases (who_calls, what_it_calls) and noun phrases (hotspots, module_map, path_between). The inconsistency is noticeable but not chaotic.
With 10 tools, the server is well-scoped for its purpose of code graph analysis and repository management. Each tool addresses a distinct need, and the count falls comfortably within the ideal range.
The tool surface covers repository lifecycle (list, index, drop) and key graph queries (find, callers, callees, impact, paths, hotspots). Minor gaps exist, such as lacking a dedicated 'get single repo' tool, but the coverage is sufficient for core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Codebase intelligence for AI agents — dead code, blast radius, ownership.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
