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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false, destructiveHint=false), so the burden is lower. The description nonetheless adds real behavioral context: results come 'from the latest run' (temporal scope), MC/DC is conditional on C/C++ with clang >= 18 (capability gating), and it includes code no linked test executes (untested-code reporting).

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 dense sentence that front-loads the core coverage types before qualifications. No filler, though the clause stacking makes it slightly heavy to parse.

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-value shape needn't be explained, and coverage content is well described. The gap is the sole input parameter and when to choose this tool over siblings, leaving an agent unsure how to scope the call.

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% for the single req_id parameter, so the description carries the compensation burden and does not meet it. It never mentions req_id, its optionality, or whether omitting it reports all requirements versus a single one.

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 resource (coverage of each requirement's implementing code) and enumerates its contents: statement/branch coverage, MC/DC, uncovered lines/branches/conditions, and untested implementing code. This is clearly distinguishable from siblings like evidence_report or trace_matrix. It never explicitly contrasts itself with an alternative, which keeps it out of 5 territory.

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 when-to-use, when-not-to-use, or alternative tools are mentioned. The agent must infer that this is the coverage-metric tool from the content alone, without routing guidance among the eleven siblings.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this is a non-read, non-destructive write. The description usefully adds the output artifacts and the ordering dependency on run_verification, but it does not disclose what happens on re-run (overwrite vs. append) despite idempotentHint=false, which is the key behavioral unknown for a write 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?

Two short sentences, no filler: the action and destination come first, and the prerequisite follows. Every clause carries information the agent needs.

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-value explanation is unnecessary, and the description covers the action, artifact, location, and ordering. The one material omission is re-run/overwrite semantics, which the non-idempotent annotation implies is relevant.

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 baseline for a parameterless tool is 4. No gap exists here, but the description also contributes nothing beyond that 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?

States a specific verb (Write) and a concrete resource (the evidence pack: Markdown + matrix JSON) with an explicit destination path (.reqtrace/evidence/). This is clearly distinguishable from siblings like run_verification, coverage_report, or trace_matrix, which produce or inspect results rather than persisting an artifact.

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 the prerequisite and sibling: 'Run run_verification first so results are current,' with the reason supplied. Usage context (for human review, after verification) is clear, but there is no explicit when-not guidance, e.g. whether it should be avoided mid-review or re-run speculatively.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the notion of a per-gap "suggested next action" and the `clean` flag semantics, but since an output schema exists this is largely redundant return-value context rather than new behavioral disclosure.

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

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

Two compact sentences with the outcome stated first and the `clean` flag second; nothing is padded. The first sentence is somewhat florid ("everything standing between this repo and...") but still front-loads the payoff.

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 format need not be explained, but the sole input parameter is undocumented everywhere and, among eleven siblings with overlapping reporting/linting purposes, no routing context is offered. For a tool in this dense a family, that leaves real gaps for the agent.

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

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

The single parameter `kinds` has 0% schema description coverage and is never mentioned in the description, so the agent cannot tell what values are valid or what filtering it performs. With low coverage and no compensating text, the description fails to carry parameter meaning.

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 conveys that this tool surfaces outstanding gaps blocking verified/signed-off requirements, which is a recognizable resource. But the framing is metaphorical ("everything standing between this repo and...") rather than a crisp verb+resource statement, and it gives no differentiation from closely related siblings such as coverage_report, lint_requirements, or evidence_report.

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 when-to-use guidance, no when-not-to-use, and no alternative tool named. The only implicit signal is "no blocking gaps remain," which hints at a pre-sign-off check but leaves the agent to guess when this is preferred over coverage_report or lint_requirements.

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

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

Annotations already disclose this is a non-read-only, non-idempotent, non-destructive write, so the safety profile is covered elsewhere. The description usefully adds that the record is escalated to a human rather than auto-resolved, but says nothing about duplicate flags, whether it mutates the requirement itself, or what the created artifact looks like. With annotations carrying the load, a 3 is appropriate.

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 zero filler; the action and its escalation target come first, and the substitution rule follows immediately. Nothing could be removed without losing routing value.

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

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

An output schema exists, so return format needn't be described, and the annotations cover the write semantics. The remaining hole is input-level: with 0% schema coverage the description leaves `description` and `related_req_ids` unexplained, which is a real gap for a 4-parameter mutation tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partly does: the enumerated problem conditions imply the `kind` values, and 'a requirement' implies `req_id`. The required `description` field and the optional `related_req_ids` parameter are never explained, leaving two of four parameters undocumented in both places.

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+resource (record a problem with a requirement) and states the outcome (for a human to resolve), which is more precise than the tool name alone. It does not, however, explicitly differentiate itself from nearby workflow siblings like record_review or find_gaps, which could also be seen as ways to surface requirement problems.

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

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

Gives explicit when-to-use triggers that map directly to the `kind` enum values (ambiguous, conflicts, can't be tested) and frames it as the alternative to guessing. What's missing is a name-check of the sibling that would otherwise be tempting (find_gaps, lint_requirements) or a note on when *not* to flag.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds what the response aggregates (code links, tests, coverage, review state, open issue count), which is useful context, but says nothing about behavior on a missing or invalid req_id.

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?

One tight sentence with the resource front-loaded and no filler. It is a noun phrase rather than a sentence, which costs a little clarity but wastes nothing.

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 the returned fields need not be re-explained, and the annotations carry the safety profile. The remaining gap is the undocumented required parameter and no note on failure behavior, which leaves a minimum-viable but incomplete definition.

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% for the single required req_id parameter, and the description never mentions it, leaving its expected format or identifier source unexplained. With a real parameter at zero coverage, the description fails to compensate.

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 fragment 'One requirement with its implementing code, linked tests, latest results, coverage, review state and number of open issues' clearly identifies the resource (a single requirement) and the depth of detail returned. It is distinguishable from the plural sibling list_requirements, though no explicit verb is used and no sibling is named.

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 singular 'One requirement' implicitly signals a per-requirement detail fetch versus list_requirements, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage must be inferred from the name and the payload 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?

Annotations already declare this is a safe, read-only, closed-world operation, so the safety burden is covered. The description adds real behavioral detail beyond that (it detects requirement text edits and deleted functions, and reports invalidated reviews), but says nothing about defaults, scope, or cost despite the two documented defaults in the 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?

Two sentences, no filler, with the core purpose front-loaded and the output content appended. The parenthetical about base_ref is well placed, though the second sentence slightly overlaps the first.

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 described, and annotations cover the safety profile. What remains thin is orientation: no guidance on when this beats trace_matrix or coverage_report, and no note on the effect of the uncommitted-changes flag, for a tool that is clearly a multi-input repository analysis.

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 carry parameter meaning. It clarifies base_ref as 'a git ref' and pins the comparison window ('since base_ref'), which is genuine added value, but include_uncommitted is entirely unexplained in both schema and description, and the HEAD default is not addressed.

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 analysis verb and its object: requirements and tests affected by changes since a git ref, including text edits and deleted functions. It is concrete and unambiguous on its own, but it never names or distinguishes itself from overlapping siblings such as trace_matrix or coverage_report.

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 rather than stated: the phrase 'Lists tests to re-run and reviews that the change invalidates' signals this is a post-change impact analysis. There is no explicit when-to-use, no prerequisites (e.g., must be run in a repo), and no routing to or away from the sibling analysis tools.

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

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

Annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the burden is low. The description adds genuinely useful behavioral context by declaring the checks are deterministic, which tells the agent results are reproducible and rule-based rather than judged. It does not discuss result volume or ordering, but that is minor here.

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 tool's function, followed immediately by the routing guidance. No filler and no repetition of the schema or annotations.

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

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

An output schema exists, so return values need no explanation, and the safety profile is covered by annotations. With zero parameters and a clearly stated scope plus an explicit hand-off to flag_requirement_issue, nothing an agent needs to select or invoke this tool 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 takes zero parameters, so per the baseline this scores 4. The description adds nothing parameter-related because there is nothing to document, and the empty schema is unambiguous (it presumably operates over the current requirement set).

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 ('requirement quality checks') and enumerates the concrete check classes (missing acceptance criteria, vague words, compound requirements). It also explicitly distinguishes itself from flag_requirement_issue, so an agent can separate the two without opening either 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?

Explicit boundary routing: this tool covers deterministic checks, while 'Judging ambiguity and conflicts is your job: use flag_requirement_issue.' This tells the agent both when to use this tool and which sibling to use instead for the excluded case.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered without the description. The description adds one piece of genuine context — that verification status is returned — but says nothing about filtering behavior, result size, or pagination.

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 wasted words. It is arguably too terse for the 2-parameter filtering surface it hides, but as pure structure it is efficient and well-ordered.

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 enumerated, and both parameters are optional so invocation risk is low. However, the filter semantics of the two optional parameters are undocumented in both schema and description, leaving a real gap for a tool whose only knobs are those filters.

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 neither parameter has a schema description, so the description carries the full burden. It mentions 'verification status', which loosely corresponds to the status enum parameter, but never explains that tag or status act as filters, nor does it clarify that status accepts one of the defined Status values.

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 (List) and resource (requirements) plus the included payload (current verification status). It reads clearly against the singular sibling get_requirement, but never names alternatives such as coverage_report or find_gaps, so it stops short of full sibling 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 description gives no when-to-use guidance, no conditions, and no exclusions. With 11 sibling tools (get_requirement, coverage_report, find_gaps, trace_matrix), an agent gets no signal about why it would choose this over them; usage is only implied by the verb '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?

Annotations already indicate a non-read-only, non-destructive write operation. The description adds important lifecycle context beyond annotations: proposed links are stored as UNCONFIRMED and do not count until a human accepts them, which explains the tool's side effects and approval requirement.

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, front-loaded with the action and scope, then the storage/approval behavior, then a usage preference. No sentence is wasted and the key constraint is not buried.

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 takes a nested array of proposed links and has 0% schema description coverage, so the description should explain parameter expectations, but it does not. It does provide the essential UNCONFIRMED/acceptance behavior and an output schema exists, but the agent is left without guidance on constructing the main argument.

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 should compensate by explaining the expected link structure. Instead it gives no details about the 'links' array, its required fields (req_id, kind, target, rationale), or the target path::qualname format, leaving parameter meaning almost entirely to the schema's type definitions.

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: 'Suggest trace links you believe exist but are not annotated.' It distinguishes the scope from normal annotations by explaining they are unconfirmed and do not count until accepted, but it does not name any sibling tool as an alternative, so it falls short of full sibling 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?

Usage is implied by 'links you believe exist but are not annotated' and the preference note 'Prefer adding annotations.' However, it never states explicit when-to-use versus when-not-to-use conditions or names an alternative tool, leaving the agent to infer the workflow.

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

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

Annotations only declare the mutation/interactivity profile (readOnly=false, idempotent=false, closed world). The description adds genuinely non-derivable behavior: a human is prompted for name and rationale, the agent cannot supply them, and a non-answer records nothing. That human-in-the-loop and failure-mode detail is exactly the context annotations can't carry.

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, front-loaded with the core action, with the human-prompt constraint and the failure mode each getting one clause. Nothing redundant; every sentence carries distinct information.

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 no explanation, and the annotations cover the safety profile; the description covers the crucial human-in-the-loop semantics and the no-op case. The only real gap is the undocumented parameters, which is a schema-side deficiency more than a description one.

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 2 required parameters, so the description must compensate — yet neither req_ids nor decision is mentioned, and the approve/reject boundary of decision is left to the schema. 'Requirements' and 'sign off' only loosely gesture at 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 action (record a human sign-off on requirements) with the key distinguishing trait that a HUMAN, not the agent, makes the call. That differentiates it from automated siblings like run_verification or flag_requirement_issue, though it never names a sibling 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?

Usage is implied by the sign-off semantics ('ask a human to sign off requirements'), and it notes the no-response outcome, but it never states when to prefer this over flag_requirement_issue or how it relates to run_verification/evidence_report. No explicit when-not 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?

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=false, so the bar is lower. The description still adds real value: it discloses that commands are sourced from .reqtrace.yaml and 'never from arguments', and that C/C++ tests each run in their own process, conveying an expensive build+instrument+execute operation. It does not say what artifacts are written, which is the only notable 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?

Four short sentences, front-loaded with the core action and then progressively adding language-specific detail. No filler. Slightly dense with implementation detail (per-test contexts, MC/DC) that could be trimmed, but each clause is informative.

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-value explanation is unnecessary, and the description covers invocation mechanics, language branching, and the config-sourced command constraint. The remaining omission is runtime/artifact side effects, which matters for a non-read-only tool but is not critical to correct invocation.

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

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

Schema description coverage is 0% for the single req_ids parameter, so the description must carry the load — and it does ('With req_ids, runs only tests linked to those requirements'), clarifying that it is a filter rather than a selector of tests to execute. It stops short of saying whether values are requirement IDs in the same format used by get_requirement/list_requirements.

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 concrete verb+resource ('Run the repo's tests under coverage and map results to requirements') and specifies per-language mechanics. It is clearly distinct from read-only siblings like coverage_report or trace_matrix, but it never names an alternative, so the differentiation is left 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 req_ids clause gives one usable condition ('runs only tests linked to those requirements'), which implies the scoped vs unscoped workflow. However, there is no explicit when-not-to-use guidance and no pointer to sibling tools such as coverage_report when the agent only wants existing data rather than a fresh run.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral content by naming the two unexpected payload categories (unrequested code and annotations naming unknown requirements), which tells the agent to expect edge-case rows. It stops short of saying whether the matrix is full-system or scoped, which matters for a tool with no filter parameters.

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 dense sentence with the primary deliverable front-loaded and the edge-case content trailing. No filler, though the arrow chain and the 'plus' clause make it slightly harder to parse than a plain statement.

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 an output schema present and zero parameters, the description need not document return fields; it correctly spends its words on scope instead. It is complete enough to call, but a reader cannot tell how this differs from the sibling reporting tools, which is the one remaining gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter claims are made that could mislead.

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 concrete deliverable: a full traceability matrix spanning requirement -> code -> tests -> latest results, plus orphan code and annotations referencing unknown requirements. That is a specific resource and scope, not a tautology. It does not, however, distinguish itself from siblings like coverage_report, evidence_report, or find_gaps, which on their face produce overlapping views.

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 when-to-use or when-not-to-use guidance and no sibling is named. An agent must infer from the content that this is the broad end-to-end traceability view rather than a filtered report, which is exactly the decision it needs help with among eleven siblings.

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