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

With no annotations provided, the description carries the full disclosure burden. It does disclose the core behavior: the tool produces a checklist derived from the file's type, and it positions the output as a safety net for ripple effects. However, it does not describe how the checklist is generated, what categories it covers, whether it depends on codebase state, or how it might behave for unknown file types. The added context is useful but shallow.

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 sentences with no wasted words. The core purpose is front-loaded in the first sentence and the usage motivation in the second. Every 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 tool with one simple parameter, no output schema, and no nested objects, the description covers purpose, behavior, and usage context adequately. The main gap is not differentiating from the sibling multi_file_checklist and not describing what the returned checklist looks like, but given the low complexity this is a minor omission.

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% for the single 'file' parameter, so the schema already documents the parameter. The description adds marginal value by clarifying that the file is 'being changed' and that its type drives the checklist, but no format, syntax, or path details are added 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 ('Generates'), a clear resource ('a checklist of things to verify'), and the basis for generation ('the type of file being changed'). This is distinct from siblings that run linters, tests, or compute impact graphs. However, it does not explicitly call out the single-file nature that differentiates it from the sibling multi_file_checklist, so it stops short of full 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 second sentence, 'Use this to ensure you don't miss any ripple effects of your changes,' gives clear usage context: invoke this when changing a file and wanting to verify side effects. But it provides no exclusion criteria, no when-not-to-use guidance, and no mention of alternatives such as multi_file_checklist or get_impact_from_diff that might be more appropriate in 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 full burden of behavioral disclosure. 'Highlights' and 'suggests checks' imply a read-only analysis, but the description does not clarify whether it reads the working tree, executes git commands, requires a certain state, or produces actionable recommendations. This is a significant transparency gap for an analysis tool with no annotation safeguards.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundancy. It states the core action and output type efficiently, and every word contributes meaning.

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 tool having seven parameters, no output schema, no annotations, and several closely related siblings, the description explains almost nothing about how the tool behaves, how inputs like diff versus files are used, what 'checks' are suggested, or what an agent should do with the result. This is well below what an agent needs to invoke the tool correctly in context.

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 all seven parameters have descriptive schema entries. The description adds the 'contract/API' framing but no parameter-level detail, so it does not meaningfully compensate beyond the schema. Baseline 3 is appropriate since the schema already documents 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 identifies a specific verb and resource: it highlights contract/API impacts and suggests checks. This helps distinguish it from generic siblings like get_impact and get_impact_from_diff by focusing on contract/API concerns, though it does not explicitly mention the diff/files input that triggers the analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus the many related siblings such as get_impact, get_impact_from_diff, or chain_effect_checklist. The description does not state prerequisites, preferred input modes, or conditions that would make this tool 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 full behavioral disclosure burden. It only states the basic return value and does not mention whether dependencies are direct or transitive, how missing files are handled, what path formats are returned, or any other operational behavior.

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 with the core action. The second sentence is largely redundant with the first, but the overall structure is acceptable and free of unnecessary detail.

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 and no annotations, the description is too minimal to fully prepare an agent for real usage. It does not explain return format, default scanning behavior, interaction with scan_dirs/src_dir/project_root, or how this tool differs from dependency-related sibling tools.

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 parameters are already well documented in the schema. The description adds no extra parameter-level context or clarification beyond the generic notion of analyzing a file.

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 returns files that a specific file imports or depends on, with a specific verb and resource. It is clear, though it does not explicitly differentiate itself from siblings like get_impact or get_impact_from_diff.

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 'Useful for understanding what a file relies on' provides an implied use case, but there is no explicit guidance on when this tool should be chosen over related sibling tools such as get_impact or get_graph_stats.

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 disclosure burden. It does convey that this is a read-like operation returning computed statistics, including circular dependency detection. However, it does not disclose whether the graph is built on demand or read from cache, what counts as a dependency, or any side effects from scanning directories.

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 one focused sentence that front-loads the action and resource, then lists the key return values. There is no filler, repetition, or unnecessary detail.

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 is adequate for a simple stats tool, but there is no output schema and no annotations, so more detail about the return shape or the computation context would help. It mentions three result categories but does not describe their structure, types, or how the dependency graph is sourced.

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 optional parameters well. The tool description does not add parameter-level meaning, but it does not need to because the schema is clear about src_dir, scan_dirs, project_root, and ignore_patterns.

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 ('Returns') and resource ('statistics about the dependency graph'), and enumerates the key outputs: total modules, total dependencies, and circular dependencies. It does not explicitly differentiate from sibling tools like get_dependencies or get_impact, but the 'statistics' framing makes the core purpose clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool instead of siblings such as get_dependencies, get_impact, or invalidate_graph_cache. The description implies a use case only through the tool name and resource, but never states the selection criteria or 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 behavioral disclosure burden. It clearly signals a read-only analysis operation with concrete return categories, which is transparent enough for a non-mutating tool. It does not discuss caching, failure modes, or performance, but these are not critical for understanding the tool's core behavior.

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 concise sentences with no filler: the first states the action, the second states the return value, and the third gives usage guidance. The information is front-loaded and 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?

The description compensates for the missing output schema by naming exactly what is returned — direct dependents, transitive dependents, and test files. It also gives a clear usage moment. It does not explicitly differentiate from get_impact_from_diff, but the single-file focus is implied strongly enough for most contexts.

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 parameters. The description mentions 'a specific file' which maps to the required 'file' parameter, but adds no deeper parameter semantics 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 clearly states a specific verb and resource: it analyzes the dependency graph to find files impacted by a specific file. It also enumerates the distinct outputs — direct dependents, transitive dependents, and associated test files — which separates it from sibling tools like get_dependencies or get_impact_from_diff.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit timing guidance: 'Use this BEFORE implementing changes to understand the full scope of impact.' It does not list exclusions or name alternative sibling tools, so it stops short of full when-not/alternative 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 must carry the full behavioral disclosure burden. It reveals that the tool can use git to discover changed files, but it does not disclose what 'impact analysis' outputs, whether there are side effects, prerequisites like an initialized git repository, or failure modes. This is a meaningful gap for a tool with no safety annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler or redundancy. The main purpose is front-loaded and the additional mode detail is directly useful.

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

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

Given the tool has 9 optional parameters, no output schema, and no annotations, the description is too thin to be complete. It does not explain what the returned impact analysis looks like, how the git discovery mode behaves across refs, or what happens when neither diff nor a valid git context is available.

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 9 parameters. The description adds a small amount of context by clarifying that either 'diff' or git-based discovery can be used, but it does not materially enrich parameter 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 ('aggregates') and a clear resource ('impact analysis across a diff or Git changeset'), making the tool's core function understandable. It is not a tautology and is distinct enough by its diff focus, though it does not explicitly contrast with the similar sibling get_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 implies usage by describing two invocation modes: providing a diff string or letting git discover changed files. It does not explicitly state when to prefer this tool over siblings or when not to use it, but the diff-oriented framing gives reasonable contextual 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys a read-only 'returns a list' outcome, but omits that this likely requires a valid git repository, performs diff and dependency analysis, scans directories, and can be shaped by refs, ignore patterns, and command overrides. The behavior is too underspecified for safe autonomous invocation.

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, grammatically simple sentence that front-loads the action and object. There is no filler, redundancy, or unnecessary elaboration; every word contributes to the core meaning.

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 11 optional parameters, no annotations, no output schema, and several closely related sibling tools, a one-sentence description is not complete enough. The agent is not told what the returned test list looks like, when to provide diff versus files, how refs and scan directories affect results, or what failure modes to expect. The schema mitigates parameter ambiguity but does not fill these 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?

The input schema covers 100% of parameters, so the baseline is 3. The description adds only a high-level relationship between 'files or diff' and the returned tests, which the schema already documents. No extra parameter semantics, combinations, or precedence information is provided.

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: it 'Returns a list of tests likely impacted' and identifies the input as files or diff. It is clear on its own, but it does not explicitly distinguish itself from siblings like get_impact_from_diff or run_relevant_tests; the distinction is only implied by the word 'Returns'.

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 explicit guidance on when to use this tool versus alternatives. The description never mentions run_relevant_tests, get_impact, get_dependencies, or get_impact_from_diff, nor does it state when to prefer this tool over running tests or computing impact. The only usage signal is the implied input of files/diff, which is insufficient in a crowded sibling set.

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 side effect of invalidating the cached graph and the direct consequence for later tool calls: 'subsequent impact analysis reflects the new state.' It does not discuss idempotency or performance, but those are minor for a no-parameter invalidation 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?

Two sentences with no filler. The action is stated first, and the usage guidance follows immediately. Every word earns its place.

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

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

For a parameter-free cache invalidation tool with no output schema, the description fully covers what the tool does and when to invoke it. It is complete relative to the tool's complexity.

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 the schema already covers everything. The baseline for a 0-parameter tool is 4; the description adds no parameter details, but none are needed.

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: 'Invalidates the cached dependency graph.' This clearly distinguishes it from sibling analysis tools like get_impact and get_dependencies, which query rather than mutate state.

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 tells the agent when to use it: 'after making changes to files.' It does not name alternatives or describe when not to use it, but for a cache-invalidation tool the usage context 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 provided, so the description carries the full burden of explaining behavior. It only restates the function ('Generates checklists') and offers no detail about side effects, output format, prerequisites, or whether the operation is read-only. This is a meaningful gap for a tool with no annotation support.

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 core action appears in the first sentence, and the usage condition in the second. Every sentence earns its place with no unnecessary detail.

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 tool with one fully documented parameter and no output schema, the description covers the essential purpose and invocation condition. It is slightly incomplete because it does not describe what the generated checklist contains or what the agent should do with the result, but overall it is sufficient for basic correct usage.

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%, with the single 'files' parameter already documented as 'List of files being changed.' The description reinforces this by mentioning multiple files, but adds no new meaning beyond what the schema already provides, 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 uses a clear verb-resource pairing: it 'Generates checklists for multiple files being changed.' It identifies the tool's purpose without confusion, though it does not explicitly differentiate itself from the sibling chain_effect_checklist, which may also relate to checklists.

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 condition: 'Use this when your change spans multiple files.' This tells an agent when to invoke the tool, though it does not mention when not to use it or point to an alternative for single-file changes.

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 present, the description carries the full burden of behavioral disclosure, yet it only states that linting errors are returned. It fails to disclose that the configurable 'command' parameter can execute arbitrary shell commands (not just lint), which may have side effects, and it says nothing about lint failures being a normal, non-exceptional outcome.

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 eight-word sentence front-loads the verb and covers both purpose and return value with zero waste. It is appropriately sized for a simple tool, though slightly terse given the absence of 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?

For a simple 2-parameter tool with full schema coverage, the description is largely adequate: it states what the tool does and what it returns. However, it does not position run_lint among its verification siblings or warn that the command parameter permits arbitrary command execution, which are meaningful gaps given no annotations or output schema.

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%, with 'cwd' and 'command' already documented including defaults, so the baseline of 3 applies. The description adds no parameter-level meaning 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 and resource ('Runs the linter') plus an outcome ('returns any linting errors'), making the tool's function immediately clear. It does not explicitly name sibling tools for differentiation, but 'the linter' is distinct enough from siblings like run_typecheck and run_tests to avoid confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus sibling verification tools such as run_typecheck, run_tests, verify_build, or get_impact. An agent is left to infer the appropriate context with no exclusions, prerequisites, or alternative routing.

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 full behavioral disclosure burden. It only restates the tool's basic action and mentions the {tests} placeholder, but does not disclose execution side effects, failure behavior, the fallback_to_full behavior, or how results are returned.

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 with the primary action. No words are wasted, though more targeted behavioral context could have been added without making it verbose.

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 are no annotations, no output schema, and five parameters, the description is insufficiently complete. It does not mention the default command, empty-list fallback behavior, return format, or how this tool relates to the broader test-related workflow.

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 parameters. The description adds minimal value by clarifying that {tests} is used in the command for precise selection, but it does not meaningfully deepen understanding of cwd, timeout, or fallback_to_full.

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 runs tests for a provided list, establishing a specific verb and resource. However, it does not explicitly differentiate this from sibling tools like run_tests or get_relevant_tests, so it falls short of a perfect score.

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 run_tests, get_relevant_tests, or other sibling tools. The instruction to use {tests} for precise selection is a mechanical detail, not context for choosing this tool over 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 carries the full burden of behavioral disclosure. It mentions auto-detection but omits side effects, expected output, exit behavior, or whether the tool modifies workspace state. Running a test command can have meaningful effects, and this description does not address them.

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 efficient sentence with no filler. The core behavior is front-loaded, and the auto-detection nuance is included economically. Every word earns its place.

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

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

Despite having only 3 parameters and no output schema, the description is too thin for an agent to fully understand invocation behavior. It does not explain what the tool returns (e.g., test results, exit code), how the test command is detected, or when to prefer sibling tools. This under-specification is significant for a tool with zero annotations and no output schema.

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 schema already documents cwd, command, and timeout with descriptions. The description adds little beyond restating that the command is auto-detected if not provided, which is already present in the command parameter's schema. Baseline 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 clearly states the operation ('Runs the project's test command') with a specific verb and resource. It is not a tautology, and the auto-detection note adds useful specificity. It does not explicitly contrast with siblings like run_relevant_tests, but the phrase 'test command' implies the full suite versus a relevant subset.

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 no guidance on when to use this tool versus alternatives such as run_relevant_tests, run_lint, or run_typecheck. There is no stated context, prerequisite, or exclusions, leaving the agent to infer appropriate usage.

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 of disclosing behavior. It does this well by specifying the exact command and the read-only nature of '--noEmit' while stating that the result is any type errors. It could add more about return formatting or failure modes, but the core behavioral model is clear.

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 purposeful sentences with no filler. The primary action is front-loaded, and the usage tip earns its place by clarifying why this tool exists alongside heavier alternatives.

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, no-output-schema checking tool, the description is complete: it states what runs, what it returns, and when to use it. No critical information for a correct invocation 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%, so the schema alone fully documents the single 'cwd' parameter. The description does not add extra meaning about parameters, but the baseline of 3 applies because no compensation is needed.

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 ('Runs'), a concrete resource ('TypeScript type checking'), and the exact command ('tsc --noEmit'), and immediately distinguishes itself from a full build. This lets an agent clearly separate it from sibling tools like run_lint or verify_build.

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 says to use this to catch type errors without running the full build, which gives clear contextual guidance. It does not explicitly name alternate tools like run_lint or verify_build, so it stops short of full when-not-to-use coverage.

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 of behavioral disclosure. It states the tool runs a build command and returns success/failure with errors, which is useful. However, it does not disclose whether the command is auto-detected, how long it may take, whether it modifies the filesystem, or what happens on timeout—information that would matter for an agent deciding how to call 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?

Three short sentences, each earning its place. The first states the verb and output, the second gives the timing, and the third states the success criterion. The most important usage guidance is front-loaded immediately after the core action.

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 required parameters, no output schema, and simple parameters, the description is nearly complete: it tells what it does, when to use it, and what counts as success. The only notable gap is the lack of mention of return format beyond 'success/failure with any errors', but given the tool's simplicity this is minor.

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 describes all three parameters, including defaults and the auto-detect behavior for 'command'. The description reinforces the tool's purpose but adds no parameter-specific detail beyond the schema. Since schema coverage is 100%, the high baseline of 3 is appropriate, and the description's clear scope slightly elevates it.

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 names the verb 'Runs' and the resource 'build command', then specifies the outcome ('returns success/failure with any errors'). It also differentiates itself from siblings like run_lint and run_typecheck by focusing on the build step. The statement 'A task is NOT complete until this returns success' adds a strong, unambiguous purpose.

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 this tool: 'AFTER implementing changes to verify the build passes.' It also provides a clear exclusion rule by implying the task is not done until success, which helps an agent know this is a final verification step. Though it doesn't name specific sibling alternatives, the timing guidance is concrete and actionable.

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