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 the JSON return, the default inclusion of working-tree changes, the behavior when ref is omitted, and the error case for non-git repositories. This is substantial and gives an agent accurate expectations beyond the tool name.

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?

Four short sentences with the core behavior first, then usage context, parameter explanation, and the sibling alternative. Every sentence contributes distinct information and there is no filler 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?

The definition is complete enough for a single-optional-parameter tool: it covers output type, parameter semantics, non-git failure, and the sibling distinction. However, with no output schema it does not detail the JSON shape or define what a 'symbol' is, which leaves slight ambiguity about the exact return structure.

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 value by providing concrete ref examples (HEAD~5, main, a SHA) and by clarifying the default working-tree behavior, but it mostly reinforces what the schema already states for the single optional 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 opens with a specific verb and resource: 'Return files and symbols changed since a git reference as JSON'. This clearly states what the tool produces, distinguishes it from siblings like ctx_diff, and includes the working-tree default. It is not a tautology and conveys the tool's exact scope.

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 explains when to use the tool ('focus an agent on what changed ... before reviewing or testing') and names the alternative for a different need ('For a per-symbol semantic diff between two refs use ctx_diff'). It also states the git-repository precondition, so an agent knows when the call will fail.

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, and it provides meaningful details: output is JSON, results are relevance-ranked, recent git changes can be included, include_bodies embeds function bodies, and max_tokens caps package size. This goes well beyond what the schema alone states, though it does not address potential costs, errors, or side effects.

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 concise and front-loaded, with the core purpose stated in the first sentence. The second sentence adds functional emphasis and usage context, and the third compacts parameter guidance efficiently. The phrase 'This is the high-value tool' is promotional but not harmful, and overall the description is well-structured and free of 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 gives the agent enough to invoke the tool correctly: a required natural-language task, optional body inclusion, token capping, and a JSON output of files/symbols/snippets. With no output schema, a little more detail about the exact output structure would improve completeness, but the description covers the essential invocation contract.

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 already has 100% description coverage for all three parameters, so the schema does the heavy lifting. The description adds useful default information ('include_bodies default false', 'max_tokens default auto') and clarifies each parameter's role, but this is supplemental rather than necessary for understanding the 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: 'Build a compact, relevance-ranked context package... and return it as JSON.' It clearly describes what the tool does and what the agent can expect from it. However, it does not explicitly distinguish this tool from its many sibling tools like ctx_symbol, ctx_skeleton, or ctx_search, so differentiation is left mostly implicit.

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 a clear usage context: 'Use when you need a focused slice of the codebase for a prompt instead of reading many files.' This tells the agent when the tool is appropriate, but it does not mention when not to use it or name alternative sibling tools. The guidance is useful but lacks explicit exclusions.

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 disclosure burden. It covers key behavioral traits: returns JSON with a specific shape, rejects path traversal, and requires an indexed project. It reasonably implies a read-only operation through 'Return' and 'Use to see'.

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 each carry distinct information: output shape and purpose, parameter constraint, and alternative tool plus prerequisite. No filler, and the most important information 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?

For a single-parameter read-only query with no output schema, the description fully equips an agent: return format, field names, path semantics, use case, sibling alternative, and prerequisite. Nothing essential is missing.

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%: the path parameter is already fully described (project-relative or absolute, outside root rejected, required). The description repeats this and adds 'traversal rejected', which is marginal value beyond the schema, so the baseline 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?

Description starts with a specific verb and resource: 'Return the outbound import edges of a file as JSON'. It names the output shape and explicitly distinguishes itself from ctx_dependents ('For the reverse direction...use ctx_dependents'), so an agent can select it correctly.

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?

States when to use it ('before refactoring it'), names the reverse-direction alternative explicitly, and gives a prerequisite ('Requires the project to be indexed'). This is clear, actionable usage guidance.

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 behavioral burden. It discloses the exact return shape, the reverse-dependency behavior, and a key security constraint: path traversal is rejected. It does not discuss potential errors for nonexistent files, but the disclosed behavior is substantial for a read-only lookup tool.

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: it leads with the operation and output shape, then the use case, then path semantics, then the sibling alternative. 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 simple one-parameter tool with no output schema, the description is complete. It provides the return format, path rules, usage context, and the relevant sibling alternative, so an agent has enough information to select and invoke the tool 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?

The single parameter 'path' has 100% schema description coverage, so the schema already documents that it must be a project-relative or absolute path outside the project root is rejected. The description mostly restates this schema meaning, adding no significant new parameter-level semantics beyond clarifying the traversal rejection.

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 purpose: it returns inbound dependency edges for a file as JSON with a specific shape, [{source, imported_symbol}]. It also distinguishes itself from the forward-direction sibling ctx_dependencies by explicitly naming the reverse direction.

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 states when to use the tool: 'Use to find every consumer of a file before changing or removing it.' It also names the alternative for the forward direction, ctx_dependencies, giving clear routing guidance for an agent.

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 full behavioral burden. It discloses the result shape (added/modified/removed symbols per file), default ref resolution, merge-base behavior, and the git-repository precondition. It does not explicitly state read-only/no side effects or empty/error behavior, but 'diff' and 'Return' strongly imply a non-mutating read 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?

Three sentences, front-loaded with the core purpose, then the sibling distinction, then invocation semantics and the key constraint. Every sentence earns its place and there is no redundant 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 tool with only two optional parameters, no output schema, and no annotations, the description communicates the result format, ref-resolution rules, and the git-only restriction. The unresolved 'or neither' case and lack of explicit side-effect or error behavior prevent a perfect completeness score, but overall the description is quite informative.

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 parameters are already fully documented in the input schema. The description largely restates the same default and merge-base semantics without adding new parameter-level detail. The 'or neither' case remains ambiguous in both the schema and the description.

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 ('Return'), a clear resource ('semantic symbol diff between two git refs'), and the output format ('as JSON'). It also explicitly distinguishes itself from the sibling ctx_changed by framing this as a structural, symbol-aware diff rather than a file list, which removes ambiguity about what the tool does.

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 names ctx_changed as the alternative and explains the structural-vs-file-list distinction, giving agents a clear selection cue. It also provides practical guidance on supplying base/head and the merge-base behavior. The 'or neither' option is mentioned but not fully clarified, leaving some ambiguity about what happens when no refs are provided.

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 disclosure burden and does so well: it specifies the report structure, the shape of impact lists, error behavior for missing targets, the indexed-project prerequisite, and depth semantics. No contradiction with annotations because none exist.

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?

Dense but structured: purpose first, output shape second, invocation constraints third. Every clause contributes necessary information for selecting and calling the tool.

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?

In the absence of an output schema, the description enumerates all report fields and list item shapes, explains unknown imports, and covers error and precondition behavior. An agent has enough to invoke the tool and interpret its result 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 three parameters are fully described in the input schema, so the baseline is 3. The description restates the one-of exclusivity, symbol/path meanings, and depth default/range without adding genuinely new semantic information 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?

Opens with a specific verb and resource: analyze the blast radius of changing a symbol or file. The ImpactReport output and pre-modification use case make it identifiable against sibling tools like ctx_dependencies or ctx_dependents.

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 instructs to use the tool before modifying code to estimate what else must be checked or updated. It does not mention when not to use it or name sibling alternatives, but the use context is clear enough for an agent.

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 full burden. It discloses the return shape, that it returns only counts and never file contents, and that indexing is required. This is strong behavioral transparency for a zero-parameter read tool.

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?

Every sentence earns its place: output format, use case, prerequisite, and sibling routing. It is front-loaded with the most important information and contains 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 no output schema, the description is complete: it explains return values, scope, constraints, and how to choose sibling tools. Nothing needed to call it correctly is missing.

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?

There are no parameters, so the baseline is 4. The description still adds value by explaining what each returned field represents (counts, paths, languages), which helps the agent interpret the output correctly.

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: returns the project overview as JSON with an explicit key list. It clearly distinguishes itself from siblings by positioning itself as the first orientation tool and referencing ctx_search and ctx_stats as alternatives.

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 when to use it: 'Use this first to orient a coding agent on a repo.' It also gives a prerequisite (project indexed) and names alternatives: ctx_stats for index-health details and ctx_search for finding symbols.

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?

There are no annotations, so the description carries the full disclosure burden. It does this well by specifying the JSON output shapes for both symbol and file modes, explaining that query matching is case-insensitive substring matching, and noting the default limit. It stops short of describing result ordering, error behavior, or empty-result behavior, but the core operational behavior is clearly disclosed.

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 dense but well-structured, leading with the core action, then result shapes, then use cases, then alternatives, then matching semantics, then constraints. Every sentence adds distinct information, and the most important behavioral 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?

For a search tool with no output schema and no annotations, this description is complete: it covers what the tool returns, when to use it vs alternatives, how query matching works, how to constrain results with kind and limit, and the file-mode behavior. An agent has enough context to select and invoke the tool 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%, so the baseline is 3. The description adds value beyond the schema by specifying the symbol result shape {name, parent, kind, path, line, signature}, clarifying that files=true produces {path, language, size}, and framing the query as a way to find definitions or file paths. This supplements the parameter descriptions with meaningful output expectations.

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 purpose with a specific verb and resource: search the project's code graph for symbols or file paths and return JSON. It further differentiates from siblings by explicitly naming ctx_symbol for deep single-symbol detail and ctx_impact for dependency 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 explicit usage context: use this to locate definitions before reading a file, or to find files by path fragment. It also names alternatives and when they are more appropriate, giving an agent direct routing guidance without needing to inspect sibling schemas.

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 behavioral disclosure burden and does it well: it specifies output shape, body-stripping behavior, path traversal rejection, supported-language error handling, and the optional stats flag. Minor gaps remain around missing-file behavior and any permissions required, but the description is notably 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 compact and well-structured: output shape first, then what the skeleton contains, then usage guidance, then parameter and error behavior. Every sentence adds useful information and there is 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?

There is no output schema, so the description appropriately explains the return shape and skeleton semantics. It also covers errors, path constraints, and the optional stats field. It would be slightly more complete if it described the exact skeleton format or file-not-found behavior, but the given level is sufficient for an agent to use the tool 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 both parameters fully. The description mostly restates the same path constraints and with_stats behavior without adding new semantic detail, so it stays at the baseline for complete 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 states a specific action and result: returning a body-less structural skeleton of one source file with a defined output shape {path, language, skeleton}. It clearly explains what the skeleton preserves and strips, distinguishing it from sibling tools like ctx_dependencies or ctx_stats.

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 context: 'Use before editing a file to understand its shape' and points to ctx_search as a fallback for path confirmation. However, it does not explicitly state when not to use this tool versus other sibling tools beyond the file-path check.

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 and does so well: it discloses read-only nature, no side effects, the JSON return shape, and the meaning of zero counts as a pending-index signal. This goes beyond the structured data and gives the agent actionable expectations.

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: purpose first, then usage guidance, then a clear sibling alternative. Each sentence contributes 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?

For a zero-parameter stats tool with no output schema, the description adequately explains what is returned (file/symbol/edge counts and index.db size), how to interpret it (all-zero means not indexed), and what to do next. No critical context is missing.

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 has zero parameters, so the schema fully covers everything there is to know. The description adds no parameter-specific detail, but none is needed; this matches the baseline for a no-parameter tool. It instead clarifies output semantics, which is more relevant here.

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: 'Return index-health statistics as JSON' with precise contents (counts of indexed files, symbols, dependency edges, index.db size). It clearly distinguishes itself from siblings by naming ctx_project as the alternative for broader project overview and implying a separate role from the graph search/impact tools.

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 tells when to use the tool: 'Use to check whether the project has been indexed' and explains the consequence of all-zero counts (must run init/indexing before graph tools work). It also names the alternative for broader overviews (ctx_project), giving clear routing guidance.

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 disclosure. It explains the return format, lists the JSON fields, and reveals that the result is an array because a name may resolve in multiple files. It does not cover error behavior or permission requirements, but for a read-only symbol lookup these are minor omissions.

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?

Four concise sentences, each earning its place: the first states the action and output shape, the second gives usage conditions, the third names the alternative workflow, and the fourth clarifies an important return-behavior nuance. It is front-loaded with the most critical information and contains 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 single-parameter tool with no output schema, the description is largely complete: it explains what the tool returns, when to use it, and why the result may be an array. It could be slightly stronger by explicitly contrasting with ctx_skeleton or ctx_dependencies, and by stating what happens when no symbol is found, but these are gaps rather than fatal omissions.

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 the single parameter with 100% coverage, calling it an 'Exact symbol name' and giving examples. The description essentially repeats this by saying 'already know the exact symbol name' and does not add meaningful new parameter semantics beyond the schema. Baseline 3 applies because the schema does the heavy lifting.

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 and resource: 'Return deep detail for a single symbol as JSON', followed by the exact output fields. It clearly distinguishes itself from ctx_search by stating that exact names are required, while fuzzy discovery belongs to ctx_search. This makes the tool's purpose unambiguous.

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 explicitly states when to use the tool: 'when you already know the exact symbol name' and need definition, signature, methods, references, and dependencies. It also provides a direct alternative and workflow: use ctx_search first for fuzzy discovery, then ctx_symbol for the best match. This is strong, actionable guidance.

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