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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds real value by disclosing the result content — filtered failing/warning validators, their messages, structured findings, and suggested next actions — which is important since no output schema exists. It stops short of describing the finding shape or whether any auth/setup is required.

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 dense sentence that front-loads the action ('Run guard') and then enumerates the output, with no filler or redundancy. Every clause contributes to telling the agent what it gets back.

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

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

For a one-optional-parameter, no-output-schema tool, the description does the needed work by summarizing the returned content and its agent-facing framing. It could be slightly more complete by stating whether findings are paginated or how next actions are represented, but nothing essential to calling it correctly is missing.

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

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

There is a single optional parameter (projectDir) with 100% schema description coverage, so the schema fully documents path resolution and the default. The description adds nothing about the parameter, which is an acceptable baseline when the schema already carries the semantics.

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 action (run the guard) and a precisely scoped output (only failing/warning validators with messages, structured findings, and suggested next actions), which clearly signals a filtered diagnostic rather than a full report. It distinguishes itself implicitly from docguard_guard (which presumably returns everything) but never names any sibling outright, so differentiation is inferable rather than stated.

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 'shaped for an agent to act on' and by the 'only what needs fixing' framing, which suggests this is the triage-then-fix entry point. However, with ten sibling tools (including docguard_guard, docguard_report, docguard_score, docguard_explain), no explicit when-to-use or when-not-to-use guidance is given, leaving the agent to infer the boundary.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured context: 'Deterministic, bounded, no model' tells the agent results are static analysis with no LLM inference, which signals reliability and repeatability beyond the 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?

A single sentence, front-loaded with the question it answers and then a compact enumeration of return categories. Dense but every clause earns its place by naming a distinct result type; only the length of the enumeration keeps it from a 5.

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

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

There is no output schema, so the description carries the return-shape burden, and it does so by enumerating the result categories along with the review state for covers= sections. Combined with 100% schema coverage on inputs, an agent has enough to call and interpret 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 100% and both parameters (path, projectDir) carry clear schema descriptions with examples, so the description does not need to restate them. It adds no format or syntax detail beyond the schema, making the baseline 3 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?

Opens with a verbatim question the tool answers ('which documentation describes this file?') and then enumerates the concrete result categories: canonical doc lines with heading/anchor/section, AGENTS.md/CLAUDE.md/GEMINI.md lines, @implements/@req IDs, @doc annotations, and covers= sections. This is specific enough to distinguish it from siblings like docguard_doc_structure and docguard_read_section.

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 question framing implies when to reach for this tool (a per-file 'who documents this?' lookup), but there is no explicit when-not guidance and no sibling is named as the alternative. The agent must infer the selection criteria from the other tools' names.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds useful output-content context (marker issues, pinned markers, last-reviewed date, size) but says nothing about side effects, permissions, cost, or limits beyond what the annotations provide.

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 dense sentence that front-loads the returned structure and ends with a clear purpose clause. It is appropriately sized for a tool with no output schema, though the long parenthetical field list is somewhat list-like rather than prose-optimized.

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

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

There is no output schema, so the enumerated return fields (headings, section markers, fact markers, marker issues, dates, size) are essential and mostly complete. Parameters are fully documented by the schema, leaving only minor gaps around relation to sibling tools and the exact response shape.

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%: doc and projectDir are both fully described in the schema, including path format and default behavior. The description adds no parameter-level meaning (no doc path syntax, no projectDir scoping details, no interaction between the two), so the 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 names the resource (a document's headings, section markers, fact markers, issues, dates) and scope (one document), so an agent knows it returns a structural outline. It implicitly distinguishes itself from the sibling read_section by noting the goal is to 'read one section instead of the whole file,' but it never states a direct verb like 'return the outline' and does not explicitly name read_section as the follow-up.

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 only implied: the closing clause suggests an agent should use this outline to locate a section rather than reading the whole file. There is no explicit when-to-use/when-not guidance, no named alternative (e.g., docguard_read_section), and no stated prerequisite or project-scope condition.

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 indicate readOnly, idempotent, non-destructive. The description adds value by detailing what the tool returns (meaning, validator, suppression), and specifies it works on 'stable' codes, providing clarity beyond 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?

Single sentence, front-loaded with verb and examples, no wasted words. Every part 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?

Given low complexity (one parameter, no output schema), the description fully explains the tool's purpose, behavior, and return value. No gaps remain.

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% with the 'code' parameter described. The description adds context about stability and case-insensitivity, and provides examples, reinforcing schema details with minimal redundancy.

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 'Explain a stable DocGuard finding code', specifying verb (explain), resource (finding code), and outputs (meaning, validator, suppression). It distinguishes from siblings like docguard_diagnose by focusing on explanation rather than diagnosis.

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

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

The description provides context on when to use it (for stable codes, e.g., STR001), and hints at usage for false positives. However, it lacks explicit when-not or alternatives, though the context is sufficient for an agent to decide.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's value is in behavior beyond that. It meaningfully discloses output semantics: deduplicated findings, per-code evidence emitted once, nextStep, coverage, and what 'full' adds — details the annotations cannot convey.

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 action and return contract, and the detail-mode explanation comes last where it belongs. Slightly dense enumeration of return fields, but every clause carries 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?

With no output schema, the description must describe return values, and it does so thoroughly (status values, findings, evidence, nextStep, coverage, claim counts). The only gap is guidance on when this tool should be chosen over its many siblings, which the usage dimension already penalizes.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns above baseline by explaining what 'full' concretely contains (per-validator finding copies, the reportable subset, raw benchmark statistics per code), adding operational meaning beyond the schema's generic 'complete guard JSON contract'.

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: running every enabled DocGuard validator against the project's canonical docs. This is clear, but it never names or contrasts itself with siblings like docguard_score or docguard_verify_claims, so the agent must infer it is the aggregate entry point.

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 only implied: running 'every enabled validator' suggests this is the comprehensive check, and the detail parameter implies a compact-vs-full workflow. There is no explicit when-to-use, when-not-to-use, or routing to docguard_score / docguard_verify_evidence.

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 the safe read-only, idempotent profile, so that half is covered. The description adds genuinely useful behavior beyond the annotations: byte bounds (8192 default / 32768 max), truncation signaling via nextOffset, and the explicit failure mode for ambiguous matches returning candidates.

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 densely-worded sentences, front-loaded with the primary behavior and the resolution order. Every clause carries information (precedence, mode switch, bounds, failure), though the packing is tight enough that a first-time reader may need a second pass.

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 9-param read tool with no output schema, the description covers return shape (section text), bounding/pagination (nextOffset), and error behavior (candidates). The main gap is that it doesn't explain how `offset` and `context` interact in practice, but the essentials for correct invocation are present.

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 already 89%, so the baseline is 3, but the description adds real meaning by defining the precedence order among id, anchor, and heading, and by clarifying that `line` switches to a windowed read around a reference. That resolution logic is not derivable from the schema alone.

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 ('Return one section's text') and enumerates the exact resolution precedence (id → anchor → heading). It names the sibling docguard_docs_for_path, so an agent can distinguish it from the other read-oriented tools.

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

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

Gives clear context for when to use the `line` mode ('the cheapest read for a table row') and names the sibling whose output feeds it. It resolves ambiguity between id/anchor/heading, though it stops short of explicit when-not-to-use guidance versus the full-document 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely non-structured behavior: the output is commit-stamped, findings are grouped by stable code, and the bundle carries a tamper-evident sha256 integrity hash — useful properties an agent cannot infer from 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?

Two sentences, no filler. The artifact and its contents are front-loaded, and the 'Evidence, not a gate' distinction is placed at the end where it acts as a routing cue 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?

With no output schema, the description must convey what comes back, and it does so thoroughly by listing the bundle's components plus the integrity hash. The main gap is routing: it does not explain how this differs operationally from the verification siblings, which an agent choosing among eleven tools would want.

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

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

There is a single optional parameter whose schema description is 100% covered, including the served-directory constraint and the default. The description adds no syntax, scope, or example beyond that, so the schema carries the full burden and baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Generate) and a well-defined artifact (commit-stamped compliance-evidence bundle), then enumerates its constituents: per-validator verdicts, findings by code, CDD score, ALCOA+ attributes, fix history, sha256 hash. The clause 'Evidence, not a gate' implicitly separates it from docguard_guard, though no sibling is named outright.

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 line 'Evidence, not a gate — it reports state without failing' tells the agent this is the reporting path rather than a pass/fail gate, which is a real usage signal. However, it never says when to prefer this over docguard_verify_evidence, docguard_score, or docguard_verify_claims, and states no prerequisites or timing (e.g., after a guard 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 readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuine value by disclosing the return contents (0-100 score, letter grade, per-category breakdown), which no output schema provides.

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 sentence, front-loaded with the core verb and result, with the output shape appended compactly. No filler or redundancy.

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

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

For a read-only single-parameter tool with no output schema, the description covers purpose and return shape adequately. It could mention the served-directory context or prerequisites, but nothing critical to 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?

There is a single parameter and the schema describes it fully (100% coverage), including the base-directory fallback behavior. The description adds nothing beyond this, so the baseline 3 for high-coverage schemas 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?

States a specific verb ('Compute') and resource ('the project's CDD maturity score') plus the output shape (0-100, letter grade, per-category breakdown). It is clearly distinct from the verify/guard/report/read siblings, though it never names a sibling to contrast against.

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 indication of when to reach for docguard_score versus docguard_report, docguard_diagnose, or docguard_explain. The agent must infer from the name alone that this is a scoring/assessment entry point rather than a diagnostics or reporting one.

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 readOnly/idempotent/non-destructive/null-openWorld, so the safety profile is covered. The description adds genuinely new behavioral facts beyond them: the packet is deterministic and mirrors a CLI invocation, and the tool voluntarily abstains under weak relevance. This materially helps an agent predict 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?

A single dense sentence with no filler, but it front-loads a CLI equivalence ('same ... as docguard agent --task ...') that is only useful if the agent knows the CLI, slightly delaying the substantive content enumeration.

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

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

There is no output schema, so the description must carry the return-value burden, and it does so by enumerating the packet's components. Combined with annotations, an agent has enough to call it correctly; only the sibling-routing guidance 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 both parameters (task, projectDir) are fully documented in the schema including the served-directory default rule. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete deliverable ('deterministic packet') and enumerates its contents: task-linked requirements, code/test pointers, excerpts, verification steps. That is specific enough to separate it from a scoring or verification tool, though it never explicitly contrasts itself with siblings like docguard_docs_for_path or docguard_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?

It notes the tool 'abstains when relevance is weak,' which hints at when results are empty, but there is no statement of when to reach for this tool rather than the ten sibling tools. An agent must infer usage entirely from the name and payload description.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context beyond that: discovery is deterministic while judgment is delegated to the LLM/caller, which clarifies the tool's role in the verification workflow.

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 are front-loaded and efficient. The first states the action and output; the second adds the key behavioral split in one compact clause.

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?

No output schema exists, so the description should convey the return shape. It does so at a high level (a verification task list) and explains the caller's follow-up role. More detail on the task-list structure could help, but the definition is adequate for a one-parameter read-only 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?

There is one optional parameter with 100% schema description coverage. The schema fully documents projectDir, its default, and scope, so the description does not need to repeat it; baseline 3 is appropriate because the description adds no parameter semantics 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 and resource: extract semantic claims (documented numbers, limits, enums) from canonical docs as a verification task list. It is clear what the tool does, but it does not explicitly distinguish this from sibling tools such as docguard_verify_evidence or docguard_diagnose.

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 as a discovery step before verification: the caller verifies each extracted claim against the code. There is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternatives among the sibling 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 declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the five possible outcome states (verified-within-scope, contradicted, stale, inconclusive, unsupported) and the per-statement scope of verification, which is exactly what an agent needs to interpret results.

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 dense sentences with zero filler, front-loaded on what is evaluated and where. The enumerated state list is slightly packed but each item earns its place by telling the agent what outcomes to expect.

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

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

With no output schema, the description usefully enumerates the return states so the agent can interpret results, and the single optional parameter is fully covered by the schema. Missing only the explicit relationship to the sibling verify 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?

Only one optional parameter with 100% schema description coverage, so the schema already fully documents `projectDir` including the served-directory default and path semantics. The description adds no parameter-level detail, which meets the baseline but goes no further.

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 (Evaluate) and a specific resource (`.docguard-evidence.json` against bounded local sources), which is far more concrete than a generic 'verify' claim. It does not, however, explicitly differentiate itself from the sibling `docguard_verify_claims`, so an agent must infer the split from the evidence-file mention.

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 sentence 'verification applies only to each selected statement' implies a scoping constraint, and 'bounded local sources' hints at the operating environment, but there is no explicit when-to-use guidance or named alternative such as docguard_verify_claims. Usage must be inferred.

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