Context-MCP

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

With no annotations, the description carries the full behavioral burden. It discloses the traversal algorithm (BFS), the result contents (file paths, relation types, traversal depth), and the notion of affected nodes. It doesn't discuss performance or side effects, but the read-oriented traversal description is reasonably 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?

Three short sentences with no filler: the first defines the algorithm and scope, the second gives the use case, and the third describes the return shape. Every sentence contributes.

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 fully described schema, no output schema, and no annotations, the description covers purpose, timing, algorithm, and return contents. It doesn't address edge cases like empty results or cycle behavior, but those are not necessary for an agent to invoke it correctly.

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 100%, so the schema already documents all three parameters. The description adds only slight reinforcement by mentioning 'node name' and traversal depth, but it doesn't provide meaning beyond 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 states a specific verb and resource: perform a BFS traversal to 'find every node that would be affected if you change it.' The blast-radius framing clearly distinguishes this from siblings like codegraph_query or codegraph_nodes, even though those alternatives are not explicitly named.

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?

It gives an explicit use case: 'Use before refactoring to understand blast radius.' This tells an agent when to invoke the tool, though it does not mention when not to use it or which sibling would be preferred for other scenarios.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states that no files are read, that it returns a module map, that it is much faster than reading files, and that it depends on codegraph_build. This is substantive behavioral context, though it does not detail error cases or exact output formatting.

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?

Three dense sentences lead with the purpose, state the prerequisite, and justify the tool's value. Every sentence earns its place with no wasted words.

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 explains the high-level return shape, the prerequisite, and the intended use. It is sufficient for an agent to select and call the tool correctly, though without an output schema a bit more detail about the exact returned structure could make it fully complete.

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 both parameters are already documented ('Project root' and 'Max files in output'). The description adds context about what the map contains but no additional detail about how the path or limit parameters behave beyond 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 uses a specific verb and resource: 'Return a module map' with every file's exported functions/classes and imports. This clearly distinguishes it from generic codegraph query tools by describing a distinct, concrete output.

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: use it to understand project structure without reading files, and call it after codegraph_build. It lacks explicit when-not-to-use guidance or named alternatives, but the provided context is strong.

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

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

With no annotations, the description takes on the disclosure burden and does add useful context: local-only execution, no API key, tree-sitter AST with regex fallback. However, it does not disclose whether a rebuild overwrites the existing graph or how/where the graph is stored.

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?

Three short sentences, purpose first, with each sentence contributing a distinct fact: what it does, how it parses code, and when to run it. There is no filler or redundant restatement.

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 absent output schema and annotations, the description still covers the tool's purpose, input type, constraints, and usage lifecycle well. A note on overwrite semantics or the fact that sibling query tools should be used afterward would make it fully complete, but it is largely sufficient for selecting and invoking the tool.

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 path and cluster are already documented in the schema. The description only reinforces the meaning of the project directory and adds no extra detail about the cluster parameter or path formatting.

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 names a specific action ('scan a project directory') and resource ('build the knowledge graph from code files'), making the tool's role immediately clear. Its build/update role is distinct from the query, report, and rendering siblings.

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?

It gives concrete usage direction: run once per project and rebuild whenever code changes. It does not explicitly enumerate when to avoid this tool in favor of a sibling, but the lifecycle guidance is clear.

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

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

With no annotations provided, the description carries the full burden of behavioral transparency. It does well by disclosing the algorithm (query matching, expansion by hops, ranking) and the return contents (compact nodes, relationship paths, budget usage, candidate counts, and per-item drop reasons). It does not explicitly state whether the tool mutates anything on disk, but the emphasis on 'returns' suggests a read/compute operation.

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-loads the core purpose, and packs meaningful behavioral and output details without redundancy. Every clause adds information about what the tool does or returns.

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 there is no output schema, the description appropriately lists the major return categories: compact nodes, relationship paths, budget usage, candidate counts, and drop reasons. It is reasonably complete for a complex graph-traversal tool. The main gap is absence of preconditions or explicit guidance on how it relates to prerequisite steps like codegraph_build.

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 100%, so the schema already documents all five parameters. The description adds some contextual meaning by tying max_hops to expansion and token_budget to the bounded nature of the result, but it mostly restates concepts already present in the schema rather than providing substantial additional parameter-level detail.

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: builds a bounded, token-budgeted context subgraph for an AI coding task, with a detailed walkthrough of the process (seed nodes, expansion, ranking, results). It is specific about verb and resource, but it does not explicitly distinguish itself from sibling tools like codegraph_query or codegraph_nodes, so it misses the upper bar for sibling differentiation.

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 'for an AI coding task' plus 'bounded, token-budgeted context subgraph' implies this should be used when the agent needs a compact, budget-limited view of relevant code relationships. However, it does not explicitly state when to prefer this over alternatives such as codegraph_query or codegraph_report, nor does it give any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does this well by stating that results are sorted by PageRank, that filters are optional and freely combinable, and by explaining filter value formats. It does not explicitly state whether the operation is read-only or how result nodes are shaped, but 'filter' strongly implies a read-only operation.

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 compact, front-loaded with the core purpose, and then uses a terse parameter key to pack filter semantics into one readable paragraph. Every clause earns its place; nothing is redundant.

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 10-parameter surface and absence of annotations and output schema, the description provides a strong foundation: it explains filtering semantics, ordering, and token budget. It lacks explicit guidance on what each returned node contains and does not clarify the required 'path' parameter, so it is not fully complete.

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 meaningful semantics for many parameters: node_type values, called_by/calls as node names, return_type as substring match, file_pattern as glob, and token_budget as max response tokens. It leaves the required 'path' parameter unexplained and relies on the schema for 'limit', which is a minor gap given 60% schema coverage.

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 opens with a clear verb and resource: 'Filter graph nodes by semantic properties.' It also conveys specific behavior like PageRank ordering and optional filters. It does not explicitly differentiate itself from siblings such as codegraph_query or codegraph_nodes, so it stops short of a 5.

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 — filter graph nodes by semantic properties — and clarifies that all filters are optional and combinable. However, it gives no explicit guidance on when to choose this tool over its siblings, nor any exclusions or alternatives.

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

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

With no annotations provided, the description does disclose noticeable side effects: it writes codegraph-cache/graph.html, graph.graphml, and an obsidian/ vault. Yet it omits overwrite behavior, prerequisites, and other consequences of running a generation tool, so behavioral disclosure remains partial.

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?

Two focused sentences with the main purpose stated first and supporting artifact details after. Each clause adds relevant information without 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 description names the main and secondary outputs and the interactive features, but omits the tree and callflow formats mentioned in the schema and does not explain format-to-output relationships or any prerequisites. Given no annotations and no output schema, some practical gaps remain.

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 100%, so both path and formats are already documented in the input schema. The description mostly repeats format names and adds output-file locations rather than clarifying parameter semantics beyond 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 opens with a specific verb ('Generate') and resource ('interactive vis.js HTML graph visualization'), then lists distinctive UI features and concrete output artifacts. This clearly differentiates it from sibling tools like codegraph_build or codegraph_query without needing additional context.

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 makes the intended use clear by describing the generated visualization artifacts and supported formats. However, it never explicitly says when to prefer this tool over siblings or when not to use it, leaving usage guidance implied rather than stated.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It does disclose the sorting order and that all nodes of a type are returned, which is useful. However, it does not state whether this is read-only, whether it requires a prior build, how results are paginated, or how token_budget/limit affect the output.

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, focused sentence that states the core action, the scope, and the ordering in an efficient way. There is no filler, and the most important behavioral detail (PageRank sorting) is front-loaded.

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 the relative simplicity of listing nodes, the description leaves important gaps: the meaning of path is unclear, the relationship between limit and token_budget is not explained, there is no output schema, and no guidance is given on how this compares with sibling tools. An agent would likely need to guess at required path semantics.

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 50%: the required path and type parameters have no descriptions, while limit and token_budget do. The description weakly clarifies type ('of a given type') but leaves path completely unexplained, and it does not explain how limit and token_budget interact. The description does not compensate for the undocumented required parameters.

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 states a specific verb and resource: 'List all nodes of a given type'. It also adds sorting behavior ('sorted by PageRank (most connected first)'), which clarifies what the tool returns. It is distinct enough from sibling tools like codegraph_query or codegraph_filter, though it does not explicitly name them.

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?

There is no guidance on when to use this tool versus alternatives such as codegraph_query, codegraph_filter, or codegraph_context. The description only implies it is for retrieving all nodes of a type; it does not mention exclusions, prerequisites, or typical use cases.

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

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

With no annotations, the description carries the full burden and does disclose output fields, combined-mode behavior, and token_budget constraints. However, it does not state whether a prior codegraph_build is required, whether the operation is strictly read-only, or what happens when neither question nor node is supplied.

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 front-loaded and information-dense, but 'or both in one call' is repeated in the later 'Pass both' sentence, creating slight redundancy. Overall, most sentences earn their 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?

The description covers the main modes and node-lookup return shape, but without an output schema it leaves question-mode response structure vague. It also omits behavior for a path-only call and the relationship to codegraph_build, both of which matter 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 schema already documents all four parameters, and the description adds real meaning beyond it: concrete question examples, the node lookup return fields, and the composition of question+node modes. This exceeds the baseline expected for high schema coverage.

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 identifies the tool's actions and resource: asking a structural question about the codebase or looking up a specific node by name, with support for combining both. However, it does not explicitly differentiate from sibling tools like codegraph_context or codegraph_nodes, although 'single-node lookup' hints at a distinction.

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 concrete conditional guidance: use question for natural-language traversal, node for single-node lookup, both for combined context, and use the tool before reading files. It does not name alternative sibling tools or state explicit when-not-to-use conditions.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It indicates that the tool returns a report and names its contents, but it does not disclose whether the report is written to a file or returned as text, whether the tool triggers a build, or what side effects or dependencies exist. This is a significant gap for a tool with no annotation safety cues.

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 concise, front-loaded sentence with no filler. The dash-separated list of report contents is information-dense and readable, and every word contributes to conveying the tool's purpose.

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 tool with no output schema, no annotations, and a vaguely defined required path parameter, the description is too thin to support confident invocation. Missing context includes what the path should point to, whether a build must already exist, whether the tool creates or overwrites a file, and what the returned value actually is. The contents list helps, but core operational details are absent.

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 single 'path' parameter has zero schema description coverage, and the description does not explain what path refers to (e.g., project path, graph database path, or output path). The description adds no meaning beyond the generic schema field name, leaving an agent to guess the parameter's role.

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 states a specific verb ('Return') and a specific resource ('CODEGRAPH_REPORT.md'), and it lists the report's contents (god nodes, clusters, surprising connections, suggested questions). It is clearly about producing a report, though it does not explicitly distinguish itself from related siblings like codegraph_html or codegraph_context.

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 explicit guidance is given about when to use this tool versus its siblings, nor are alternatives named. The phrasing implies it is used when a report is needed, but there is no context about prerequisites such as requiring a prior codegraph_build, or when a different tool would be more appropriate.

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