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 says the tool identifies affected files but does not disclose output format, analysis depth, limitations, or whether it is read-only.

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?

It is a single, front-loaded sentence with no wasted words. It is appropriately concise for a short tool definition, though it could include a bit more routing or behavioral context without becoming bloated.

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 absence of annotations and output schema, the description should explain more about what the agent gets back and how the analysis behaves. It leaves key details like return format and analysis scope unspecified.

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 is one parameter with 100% schema description coverage, so the schema already documents that filePath is the modified file path. The description adds no syntax, format, or semantic detail beyond the schema baseline.

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: identify files affected by modifying a target module, with the clarifying term blast radius. It is clearly distinct from sibling tools like find_symbol or trace_dependencies, though it does not explicitly name an alternative.

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 implies usage for impact analysis but gives no explicit guidance on when to choose this over trace_dependencies, assess_change_risk, or analyze_project. There are no exclusions, prerequisites, or alternatives mentioned.

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 exist, so the description carries the full burden. It usefully discloses the content of the result (frameworks, package manager, language distribution), implying a read-only static analysis, but says nothing about scope (repo-wide scan?), cost, failure modes on non-project directories, or whether results are cached. Adequate but with clear gaps for an unannotated 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?

A single front-loaded sentence listing the detected artifacts, with no filler or redundant restatement of the 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?

With no input schema, no annotations, and no output schema, the description does enough by enumerating what the analysis returns. The remaining hole is sibling disambiguation against get_project_context, which matters given how similar the two names are.

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 is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies the operation needs no arguments.

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 ('Map') and enumerates the concrete outputs: structure, frameworks, package manager, language distribution. An agent knows exactly what this tool produces. However, it never distinguishes itself from the sibling get_project_context, which sounds like it could return overlapping information.

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 statement of when to reach for this tool versus get_project_context, find_symbol, or get_project_diagnostics. The only guidance is implicit in the verb 'Map' and the fact that it takes no parameters, which an agent must 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?

No annotations are provided, so the description carries the full burden. It does usefully disclose the method ('complexity and dependency signals') and the return scale, which compensates for the missing output schema, but it never states whether the operation is read-only or has 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?

A single tight sentence with the core action and outcome levels front-loaded and no filler. It is efficient, though its brevity veers toward under-specification rather than optimal coverage.

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 one-parameter assessment tool with no annotations and no output schema, the description is minimally adequate: it names the outcome levels but not the thresholds that define them or how composite signals map to each level. An agent could invoke it, but not interpret the result meaningfully.

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?

With a single parameter at 100% schema description coverage, the schema already documents filePath fully, establishing the baseline of 3. The description adds no format, path-resolution, or scoping detail beyond what the schema 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 states a specific verb plus resource ('Assess modification risk') and enumerates the possible outcome levels (LOW/MEDIUM/HIGH/CRITICAL), so the agent knows exactly what this tool produces. It does not explicitly differentiate itself from siblings like analyze_impact or detect_dead_code, which keeps it at a 4.

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 prefer this tool over analyze_impact, trace_dependencies, or the other siblings, and no stated prerequisites or exclusions. The agent must infer the selection criteria from the name alone.

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 exist, so the description carries the full burden, and it discloses almost nothing: it doesn't say whether the scan is read-only, whether it covers the whole project or a subset, how expensive it is on a large codebase, or what it returns. Only the scope 'unreferenced exports' hints that non-exported dead symbols are excluded.

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?

A single front-loaded sentence with zero filler. It is efficient, though its brevity is partly under-specification rather than pure tightness.

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?

With no annotations and no output schema, the description is the only source of behavioral information, and it omits the return shape (a list of symbol names? locations?), whether the result is exhaustive or heuristic, and any cost consideration for a whole-project scan. Complexity is low (0 params), but the disclosure gap is still meaningful.

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 is no parameter semantics for the description to explain; the baseline of 4 applies. Nothing in the description misleads about inputs.

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?

A specific verb ('Identify') plus a precise target ('unreferenced exports') scoped to the project. It is distinguishable from siblings like find_symbol or trace_dependencies by naming dead-code detection as its job, though it never explicitly contrasts itself with 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 statement of when to run this versus analyze_project, get_project_diagnostics, or trace_dependencies, nor any prerequisite (e.g., analyzed project state needed first). Usage is only implied by the word 'project'.

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, yet it says nothing about matching semantics (substring vs fuzzy vs case sensitivity), search scope (whole project vs open files), result limits, or whether results include file/line locations. For a search tool with zero annotation coverage this is a substantial gap.

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?

A single front-loaded sentence with no filler and the resource enumeration placed early. It is efficient, though the brevity comes at the cost of the behavioral detail noted above.

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?

With no annotations and no output schema, the description is the only place an agent could learn what a match looks like (file path, line, kind) and how many results come back, and it supplies neither. For a lookup tool the caller cannot predict the response shape from any structured field.

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 parameters (name, exactMatch) are already documented in the schema. The description adds only the scoping hint "across the project" and does not elaborate on how exactMatch changes matching behavior or what name forms are accepted, 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 gives a specific verb ("Locate") and enumerates the resource kinds it covers (functions, classes, interfaces, types, variables), which is more informative than the bare name. It does not, however, distinguish itself from siblings like analyze_project or trace_dependencies, so the agent must infer where symbol lookup ends and analysis begins.

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 statement of when to use this tool versus the six sibling analysis tools, no prerequisites, and no exclusions. Usage is only implied by the word "Locate"; an agent choosing between find_symbol and analyze_project gets no routing help.

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 implies a read-only operation via 'Return' but says nothing about what the payload contains, how large it is, whether it is cached or scoped to a workspace, or what happens on a fresh/empty project.

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?

A single front-loaded sentence with no filler; 'concise, token-optimized' is doing real work about the shape of the output. It is efficient, though it spends its limited budget on framing rather than on concrete content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is structurally simple (zero params, no nested objects), which lowers the bar, but there is no output schema and no annotation coverage. With nothing else describing the return value, the description should say what 'context' actually comprises; as written, an agent must call it blind to find out.

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 is nothing for the description to disambiguate. Baseline of 4 applies; the description is not penalized for omitting parameter guidance that cannot exist.

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 verb 'Return' and resource 'project context' are stated, along with a value claim ('concise, token-optimized'), but 'project context' is left undefined — an agent cannot tell whether this yields file trees, symbol summaries, or diagnostics. It also fails to distinguish itself from close siblings like analyze_project and get_project_diagnostics.

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 only usage signal is the audience phrase 'for AI coding agents', which describes the consumer rather than the situation. There is no when-to-use, no when-not-to-use, and no mention of the six sibling tools that could plausibly serve overlapping needs.

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 disclosure burden. It says what is reported but not the scope (whole project vs. current file), whether it is read-only, whether it can be slow on large codebases, or how results are presented.

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?

A single front-loaded sentence with no filler; the two diagnostic categories are delivered immediately. Nothing is wasted.

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 should say which project context it operates on and roughly what the report contains. It names the findings but leaves scope and output shape implicit.

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 is nothing for the description to disambiguate; the absence of arguments implicitly signals a whole-project scan. Baseline 4 applies 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?

States a specific verb ('Report') with two concrete outputs: broken imports and circular dependency loops. That makes it distinguishable from siblings like detect_dead_code or trace_dependencies, though it never names or contrasts those siblings explicitly.

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 reach for this tool versus analyze_project, trace_dependencies, or detect_dead_code, and no stated preconditions such as requiring an indexed or loaded project. The agent must infer usage entirely from the tool name and 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?

No annotations are provided, so the description carries full behavioral burden. It implies a read-only trace but never confirms non-mutation, doesn't say whether traversal is transitive or single-level, gives no depth/scope limits, and says nothing about output shape for a tool with no output schema.

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?

A single tight sentence that front-loads the verb and enumerates the dependency categories. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter trace tool this is minimally adequate, but with no annotations and no output schema the agent still lacks behavioral detail (transitivity, output format, error behavior on missing files). Some important context is left to inference.

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?

Only one parameter (filePath) with 100% schema description coverage, so the schema already documents the input. The description adds no path format, resolution rules, or root-relative vs absolute details beyond the schema. Baseline 3 applies since 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?

Names a specific verb ('trace') and resource ('dependencies of a file'), and enumerates the dependency directions (incoming, outgoing, external). It is clear what the tool does, though it doesn't explicitly distinguish itself from siblings like analyze_impact or detect_dead_code, which also operate on files.

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 choose this over analyze_impact, detect_dead_code, or find_symbol. No prerequisites, no exclusions, no mention of what kind of question this answers versus its siblings.

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