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

No annotations are supplied, so the description carries the full behavioral burden, and it does meaningful work: it states the external dependency ('coverage' installed in the project's interpreter, with the error naming it), and that coverage data goes to a temp dir and nothing is written into the project. It omits runtime cost and side effects of actually executing the test suite (the 600s default timeout hints at this but is not explained).

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 output shape and dependency requirement are front-loaded, followed by per-parameter notes. Prose is tight with no filler; the only weakness is that the parameter notes are not labeled for the two undocumented parameters, so the reader cannot tell whether they are intentionally omitted.

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

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

An output schema exists, so return values need not be explained, and the description covers the key dependency and write-safety behavior. But for a six-parameter test-execution tool with zero annotation coverage, leaving four parameters (including python, runner, and timeout) unexplained means an agent cannot confidently control the run.

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 0%, so the description must compensate. It explains two of six parameters well -- 'files' (formats and globs, plus the surprising default of 30 least-covered files) and 'selector' (partial suite). 'path', 'python', 'runner', and 'timeout' receive no explanation at all, leaving a substantial gap.

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 and resource: run Python tests under coverage.py and report per-file percent plus uncovered line ranges, with an example format ('12-15, 20'). It is clear what the tool produces, though it never names or contrasts itself with the sibling run_tests, so an agent must infer the difference.

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?

Usage context is implied by 'Python projects only' and by the selector note ('run only part of the suite'), and the default behavior (30 least-covered files plus total percent) tells the agent what happens if it omits files. However, there is no explicit when-to-use vs run_tests / rerun_failed guidance, which matters given six sibling tools in the same suite.

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

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

With no annotations, the description carries the full burden and does substantial work: it declares the read-only nature, enumerates what evidence is gathered per candidate, and explains that readiness depends on pytest being importable or node_modules existing. It stops short of saying what happens when nothing is detected or how costly the scan is.

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 key scoping claim is front-loaded in the first sentence, followed by supporting detail about what is inspected and returned. It is slightly long and the trailing parameter lines are terse fragments, but no sentence is padding.

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 two-parameter, read-only detection tool with an output schema, this covers what it inspects, how readiness is judged, interpreter resolution, and even test directories. The only real gap is the no-runner-detected case, a minor omission given the return schema exists.

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 0%, so the description must compensate, and it does: 'path' is described as the project root with the advice that absolute is safest, and 'python' is described as an optional interpreter path or the literal 'uv'. Both parameters get meaning the bare schema lacks, though the exact 'uv' behavior is left implicit.

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 — 'Detect which test runner a project uses' — and immediately scopes it with 'without running any of its tests', which cleanly separates it from run_tests and rerun_failed. An agent can pick this out of the sibling list without opening the schema.

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 'without running any of its tests' implies a pre-flight/inspection use, and the readiness checks hint that this precedes actual execution. However, no sibling is named, no explicit when-to-use or when-not-to-use rule is given, and the agent must infer the relationship to run_tests or list_tests.

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

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

With no annotations, the description carries the burden well: it discloses that the tool re-executes the test (a real side effect with cost), enables --showlocals for pytest, caps output at 20k chars, and reports when a test passes in isolation. That 'passes alone' behavior is exactly the kind of non-obvious trait an agent needs. It omits permission/environment requirements and how long an isolated run may take beyond the schema's timeout default.

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, front-loaded with the core action and output shape, with no filler. The mid-sentence parenthetical about --showlocals interrupts flow slightly but adds real information rather than padding.

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

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

An output schema exists, so explaining return values is optional — the description does so anyway and adds value with the 20k cap and pass-alone case. What's missing is parameter guidance for a five-parameter tool with zero schema descriptions, which leaves a real gap before the agent can call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are five parameters, so the description must compensate — it does not. path, python, runner, test_id, and timeout are never explained; only a passing parenthetical ('for pytest') hints that runner relates to the test framework. An agent must guess formats for test_id and how python/runner interact with autodetection.

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 narrow scope: 'Full detail for one failing test' with a re-run under extended tracing. An agent can tell this is a deep-dive single-test diagnostic rather than a suite run. However, it never names or contrasts with siblings such as rerun_failed or flaky_check, which overlap on the 'rerun and detect flakiness' angle.

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?

Usage is implied by the phrasing 'one failing test' — call it when you already have a known failure and need detail. There is no explicit when-not guidance or statement of which sibling to use first (e.g. run_tests vs rerun_failed vs this). The flaky/order-dependent clause hints at a related use case but doesn't route the agent between this and flaky_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?

No annotations are supplied, so the description carries the full burden and does it well: it discloses process isolation per run, the n range (2-20), the worst-case cost ('n x timeout seconds'), the verdict taxonomy (flaky | stable_pass | consistently_failing | inconclusive), and that failure details for the first failure are included. It also warns about a false-negative mode (passing here despite order-dependent flakiness).

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?

Front-loaded with the action and the return shape, then cost, then the false-negative caveat, then the id format. Dense but nearly every sentence earns its place; the verdict enumeration is slightly redundant with the output schema but still aids interpretation.

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 6-parameter test-execution tool with an output schema, the description covers the essential contract: what it runs, how many times, what it returns, and how long it can take. The remaining gap is what 'path' and 'runner'/'python' mean operationally (project root vs file path, runner override semantics).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate; it does so strongly for test_id (exact id formats for pytest, jest/vitest, unittest) and gives the n range plus the timeout relationship implicitly via the cost formula. However, path, python, and runner are never explained, leaving half the parameters undocumented in both schema and 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 and scope: 'Run ONE test n times... and report the pass/fail pattern', with 'ONE' and 'fresh process' making it distinct from suite-level siblings. The named alternative (run_tests) further separates it from run_tests/rerun_failed.

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 routes an important adjacent case: a test that is only flaky under ordering/parallelism/shared state 'can pass here; check that with run_tests on the surrounding file.' That is real when-to-use-which guidance. It stops short of stating hard preconditions (e.g., when to skip flaky_check entirely), so not a 5.

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

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

With no annotations, the description carries the full burden and does real work: nothing is executed, output is capped at 500 ids, and collection errors (import errors in test modules or conftest.py) are reported separately rather than as failures. It leaves timeout behavior and failure modes on bad paths unexplained.

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?

Front-loaded with the collect-only distinction and the return shape, then a compact block on filter and consumer wiring. Dense but every sentence contributes; no marketing 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?

The existence of an output schema reduces the need to describe return values, and what's said about ids and errors is adequate. But for a six-parameter tool with zero schema descriptions and no annotations, the unexplained `selector`, `runner` and `timeout` leave the definition short of what an agent needs.

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 0% across six parameters, yet only `filter` is explained (per-runner semantics: -k expression, unittest name pattern, file-name substring). path, runner, python, timeout and especially `selector` receive no meaning at all beyond their bare titles.

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 plus the crucial negative scope: "List the tests without running them (collect-only)". That single clause separates it unambiguously from the sibling run_tests, and it also names what comes back (ids, collection errors).

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

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

Gives forward routing explicitly: use the returned ids as run_tests selectors and as flaky_check / explain_failure test_id, and warns that for jest/vitest only test FILES can be listed. It stops short of saying when to call detect_runner first or when a list is unnecessary.

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

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

With no annotations, the description carries the burden and does reasonably well: it discloses the at-most-100 rerun cap, that the returned structure matches run_tests plus a rerun count, and that the stored failure list is replaced by remaining failures (a state mutation). It omits error behavior when no prior failure list exists and any permission/execution 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?

Three tight sentences, front-loaded with the core action, then return shape, then the 100-cap and failure-list replacement. No redundant or filler wording.

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 output schema and the description cover return values well, and the prerequisite of a prior run in the same session is stated. However, for a three-parameter tool with zero schema documentation, the absence of any parameter guidance leaves the definition only partially complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across three parameters (path, python, timeout), and the description does not mention any of them. The phrase 'this project' hints at path scoping, but there is no guidance on what python or timeout control, so the description fails to compensate for the coverage gap.

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 precise verb and resource ('Re-run only the tests that failed or errored') and constrains it to the last run_tests/rerun_failed in the same server session, which cleanly separates it from the sibling run_tests (full run) and list_tests.

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 the when: after a prior run_tests/rerun_failed has produced failures, within the same server session. That is a clear trigger context, but it never explicitly says when to prefer run_tests instead of this tool or what happens if there is no recorded failure list.

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

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

With no annotations supplied, the description assumes the full disclosure burden and does it well. It prominently warns that project code executes, enumerates possible outcomes, explains failure and collection-error reporting, identifies the active test on timeout or crash, states that the entire process tree is killed at timeout, and discloses refusal of non-allow-listed extra arguments.

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 purpose and code-execution warning are front-loaded, and the parameter guidance is compact and easy to scan. The long output catalog is somewhat dense and partly unnecessary because an output schema exists, although most of its details convey useful behavioral distinctions rather than 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 six-parameter tool that executes arbitrary project code, this provides nearly enough operational, safety, and result-interpretation context to invoke it correctly, with the output schema supplementing the return-value details. The unexplained path parameter and lack of guidance about non-executing or more specialized siblings remain meaningful but limited 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?

Despite 0% schema description coverage, it documents selector with framework-specific syntax and a default, timeout with units and bounds, extra_args with examples and its allow-list restriction, python with accepted interpreter forms, and runner with supported values and auto-detection. The path parameter is not explained, leaving its relationship to the project, selector, and working directory unclear.

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 opening sentence clearly states the verb and resource: run tests and return counts plus focused failure details. The supported runners and selectors further clarify scope, but the description does not explicitly distinguish this tool from execution-related siblings such as rerun_failed or flaky_check.

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 practical invocation guidance: run everything by default, select files, directories, node IDs, or framework-specific patterns, force a runner when needed, and consult detect_runner for auto-detection. It does not explain when not to execute tests or when siblings such as list_tests, coverage_summary, or rerun_failed are preferable.

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