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

With no annotations, the description carries the safety/behavior burden. It discloses what the call produces and signals efficiency by replacing 'a dozen exploratory file reads', making the operation's analytic, non-mutating nature clear through the 'you get...' framing. It stops short of stating any performance or read-only caveats explicitly.

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 dense sentences with no filler; the purpose is front-loaded and the supporting details (what it returns) are listed compactly. Each clause 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?

For a single-optional-parameter tool with an output schema, the description covers the key contextual information: when to use it, what to expect, and why it is valuable. Nothing critical is missing 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 coverage is 100%, and the single include_diagram parameter is fully documented in the schema. The description adds no parameter-specific guidance beyond the schema, so the baseline 3 applies.

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 verb and resource ('Orient yourself in an unfamiliar repo') and enumerates concrete outputs (module sizes/layering, import cycles, PageRank hotspots, entry points). It clearly differentiates from symbol-level siblings like find_symbol and who_calls by positioning itself as the repo-level starting point.

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?

'Start here' and 'one call replaces a dozen exploratory file reads' provide explicit context for when to use it: early exploration of an unfamiliar codebase. It does not explicitly state when not to use it or name an alternative, so it misses the full 5.

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 of behavioral disclosure. It explains the internal approach (combining reverse import graph with reverse call graph), the recall-first bias with a specific confidence threshold of >=0.3, and the rationale that missed impacted tests are worse than extra ones. It does not explicitly state that the operation is read-only or safe, but the impact-analysis framing implies it.

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 short and front-loaded: the purpose is in the first sentence, methodology and behavior in the second, and usage guidance in the final sentence. Every sentence adds distinct value with no repetition or filler.

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 output schema is present and the parameter schema fully describes the inputs, the description provides the necessary context: what the tool computes, how it prioritizes recall, what it highlights, and when to call it. An agent has enough to invoke it correctly and interpret its role relative to siblings.

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%, and the schema already documents target, depth, and limit with meaningful descriptions. The tool description adds no parameter-specific guidance beyond the schema, so the baseline score of 3 is appropriate.

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 purpose: 'Impact analysis: what a change here could break, and which tests to run.' It also differentiates itself from siblings by explaining it combines the reverse import graph with the reverse call graph and specifically highlights test files, which sets it apart from who_calls, what_it_calls, and related_symbols.

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 context for when to use the tool: 'Call this before editing shared code and after finishing, to pick tests.' It does not explicitly name alternatives or state when not to use it, but the workflow guidance is clear and actionable.

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 burden of explaining behavior. It discloses what the outline contains (definitions, imports, importers) and notes that it is cheaper than full file reading. It does not discuss edge cases like partial paths, errors, or cache behavior, but for a simple summary tool this 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?

Two compact sentences put the core purpose first and the cost/use-case benefit second. Every sentence earns its place; there is no filler or redundant restating of the tool name.

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 single-parameter tool with an output schema, the description explains what the result contains and why one would choose this tool. It could be slightly stronger about how this compares to adjacent sibling tools, but nothing essential is missing for a basic 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 coverage is 100% and the sole parameter is already well described. The description adds no new parameter-level detail, which is acceptable since the schema fully documents the path parameter.

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 scope: an outline of one file covering definitions, imports, and reverse-imports. This distinguishes it from generic search or symbol tools by naming the specific resource and output aspects.

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 explicitly frames the tool as a cheaper alternative to reading a file when only relevance matters, and highlights the reverse-import advantage. It does not name sibling tools or provide explicit when-not-to-use guidance, but the intended scenario 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?

No annotations are present, so the description carries the burden. It discloses a key behavioral trait: results are 'ranked by structural importance', illustrated with the six-run-functions example. It also mentions exactness and the output shape, though it does not discuss limitations like auth or rate limits.

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 sentences with no filler: the main purpose is front-loaded, the ranking behavior is immediately explained, and the alternative tool condition is given once. Every sentence 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?

An output schema exists and the parameter schema is fully documented, so the description need not restate return types or parameter details. It supplies the missing context: when to use, how results are ranked, and when to switch to search_code, making it complete for an AI agent.

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 four parameters. The description adds little beyond contextual emphasis on exactness and ranking; it does not deepen meaning for kind, lang, name, or limit 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?

States a specific verb and resource: 'Locate where a symbol is DEFINED', with concrete outputs (file:line, signature, doc). It also distinguishes from the sibling search_code by positioning itself as the exact lookup for known symbol names, so an agent can tell when to use it.

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?

Explicitly says this is the right first call for 'where is X?' and names the alternative: use search_code when you only know roughly what the thing does. This gives clear selection criteria without the agent needing to infer.

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 usefully states the returned artifacts (definition plus graph neighborhood) and the include_source toggle, but does not explain depth behavior, error cases, or cost of deep traversal. This is adequate but not deeply 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?

Two tightly packed paragraphs with no filler. The core purpose is in the first sentence, and the practical guidance follows immediately. Every sentence 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 output schema exists and parameter docs are complete, the description covers the essential context: what the tool returns, why to prefer it, and when to enable source. It doesn't cover depth semantics or error behavior, but those are partially covered in the schema and are minor for a read-only lookup 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 the baseline is 3. The description adds meaningful usage semantics for include_source ('when you intend to modify it') that goes beyond the schema, and the symbol parameter's accepted forms are already well documented in 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?

States a specific verb and resource: 'Full detail for one symbol' with concrete contents (signature, doc, members, callers, callees). This clearly differentiates get_symbol from siblings like search_code, who_calls, and what_it_calls by scoping it to a single symbol's combined 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?

Gives explicit usage guidance: prefer this over reading the whole file, and set include_source=true when you intend to modify the symbol. It does not explicitly name all sibling alternatives or when those would be better, but the 'prefer this over...' framing gives clear decision context.

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 burden of behavioral disclosure. It explains what the tool reports, including size, coverage, resolution breakdown, and indexed_at, and adds diagnostic meaning beyond a simple field list. It does not explicitly state that the tool is read-only, but for a stats tool this is strongly implied by the content described.

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 and front-loaded: the first sentence states exactly what the tool reports, and the second sentence gives actionable usage guidance. Every sentence earns its place with no filler.

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 tool with an output schema available, the description provides everything needed to decide when and how to use it. It explains the tool's purpose, the data it returns, and the diagnostic scenario in which it is useful, leaving no meaningful gap.

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 tool takes zero parameters, so there are no parameter meanings to clarify. The description still adds conceptual value by naming the key output dimensions (size, coverage, edge-resolution breakdown, indexed_at), which is appropriate for a parameterless tool.

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 resource and content ('Index health: size, coverage, and the edge-resolution breakdown by rule'), which immediately distinguishes it from the symbol-focused sibling tools. However, it lacks an explicit verb like 'reports' or 'returns', so it falls just short of the strongest purpose 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 an explicit trigger: 'Worth a call when graph answers look thin'. It also explains how to interpret results ('low resolution rate or a stale indexed_at tells you the index needs rebuilding rather than the code being unusual'), which is excellent practical guidance for when this tool is the right choice.

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 burden, and it delivers: it discloses the algorithm (personalized PageRank), the undirected treatment of the call graph, and the non-obvious behavior of surfacing siblings/helpers rather than direct edges. It also clarifies that no embeddings are required, which is a meaningful operational trait. It stops short of explicit statements about read-only-ness or side effects, though the reading context strongly implies a safe query.

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: a one-line use-case question, a two-sentence explanation of the algorithm and its value, and a one-sentence positioning against semantic search. It front-loads the user intent and each sentence earns its place. No redundant restatement of schema or annotations.

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 moderate algorithmic complexity, and the description covers purpose, algorithm, outputs' conceptual nature, and how it differs from structural and semantic alternatives. An output schema exists, so not detailing the return payload is fine. The only minor gaps (exact sibling names, explicit exclusions) are small and already addressed in other dimensions.

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 covers both parameters with descriptions ('Anchor symbol (name, qualname or id)', 'Max results'), so the baseline for this dimension is 3. The description reinforces that symbol is the seed of the PageRank but adds no syntax, defaults, or format details beyond the schema. This is acceptable given high 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 defines a concrete operation: it runs personalized PageRank seeded on an anchor symbol over the call graph, computed undirected, to surface related symbols. It immediately distinguishes itself from sibling tools like who_calls/what_it_calls by stating it goes beyond a plain caller/callee list. The 'structural analogue of semantic search' framing makes the resource and intent unmistakable.

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 frames when to use it: when deciding 'what else should I read before touching this,' and contrasts it with a plain caller/callee list for discovering indirect collaborators. It indicates this tool is the structural alternative to semantic search and does not need embeddings, which guides tool selection. It does not explicitly name sibling tools or state a hard when-not-to-use, so it falls just short of a 5.

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?

Annotations are absent, so the description carries full behavioral disclosure. It discloses that search uses BM25 and that results are re-ranked by call-graph importance, which is valuable non-obvious behavior. It could mention pagination or query-syntax details, but the core operation and ordering semantics are 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 sentences with no filler: the first defines scope, the second states when to use it, and the third explains ranking behavior. Every sentence earns its place, and the key use-case guidance 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?

Given the output schema and only two straightforward parameters, the description is nearly complete. It covers the tool's purpose, use case, searchable content, and result ordering. It does not explicitly state exclusions or name the exact-identifier sibling, but the sibling context and 'not the identifier' phrasing make the intended boundary clear.

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 describes both parameters completely, so the baseline is 3. The description reinforces that `query` is free-text and explains why certain matches outrank others, but it does not add per-parameter syntax or formatting detail beyond what the schema already provides.

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 ('Full-text search') and a precise resource scope ('symbol names, signatures and docstrings'). The phrase 'Use when you know the intent but not the identifier' clearly distinguishes it from exact-identifier lookup tools such as find_symbol.

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 usage condition: use it when the intent is known but the identifier is not. It does not name the alternative tool directly, but the contrast with exact-lookup siblings is strongly implied by the wording and the sibling list.

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 behavioral burden. It discloses the transitive, graph-walking nature of the tool, but does not mention performance characteristics, result size limits, or other runtime behavior beyond what the schema hints at.

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 and front-loaded, with the core definition in the first sentence and practical guidance in the second. No filler or redundant restatement of the tool name.

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 provides enough context for an agent to understand the tool's purpose and basic invocation. Some gaps remain around parameter semantics and explicit sibling differentiation, but the output schema and schema constraints partially fill those 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 only 50%: symbol and depth are documented, but limit and min_confidence lack descriptions. The tool description does not compensate by explaining these parameters or clarifying their units/purpose.

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: build a forward call tree of what a symbol transitively depends on. This distinguishes it from reverse-call tools like who_calls, though it does not explicitly name 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?

The description provides concrete use cases: understanding an unfamiliar function without reading every file, and identifying the layer a piece of code sits in. It gives clear context but does not state when to prefer an alternative tool or when not to use this one.

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 behavioral burden. It discloses that each edge reports the rule that produced it and warns that sub-0.5 edges are leads rather than facts. It does not discuss cost or traversal size, but the output schema covers result shape.

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 compact sentences deliver the definition, the trigger scenario, and the confidence caveat. The description is front-loaded with the core purpose and every sentence adds distinct value.

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 read-only analysis tool with a full output schema and fully documented parameters, the description covers what the tool computes, when to use it, and how to interpret weak results. Nothing essential is missing for selecting and invoking 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?

All four parameters already have schema descriptions, so the baseline is 3. The description adds meaningful semantics for min_confidence, explicitly saying sub-0.5 edges should be treated as leads, and implies that depth and limit control transitive expansion.

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 action and resource: 'Reverse call tree: everything that reaches this symbol, transitively.' This clearly distinguishes it from forward-call tools like what_it_calls without needing extra inference.

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 guidance on when to use the tool: 'The tool to use before changing a signature, tightening a validation, or deleting anything.' It does not explicitly list exclusions or alternatives, but the use-case framing is clear and actionable.

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