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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, but the description adds real value beyond them: server-side vs browser compute delegation semantics, the guarantee that inputs 'are not stored, logged, or retained,' determinism of the compute node, and the AP2 artifact with execution_hash emitted on export. The privacy/data-handling and delegation behavior are exactly the kind of context annotations cannot convey; it stops short only of describing failure modes or error 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 large share of the text is regulatory boilerplate—deadline 2027-12, Digital Omnibus, Parliament approval June 2026, KYA-OS donated to DIF March 2026, FV-status hash path—that does not help an agent decide or invoke. The genuinely useful summary of what the tool checks is buried at the very end rather than front-loaded, forcing the reader past multiple paragraphs of provenance before reaching the operation.

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

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

The description names the returned fields (overall_status, pass, fail, warn, checks, root_agent_id, scopes) and points to describe_tool for the full output shape, which compensates for the absence of an output schema. Combined with the stated validity-window and chain-depth rules and the compute-mode explanation, an agent has enough to call it correctly; only explicit error/failure handling 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 description coverage is 100% and there are no required parameters, so baseline is 3. The description repeats the compute-mode semantics (auto/server/browser) and restates that credential and validate_at_unix are required, both of which are already in the schema, adding little new meaning for how to shape inputs.

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

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

The closing summary states the specific operation precisely: 'KYA-OS credential-chain attestation: delegated-authority credential chain, scope limits, validity windows (max 90 days), chain depth cap (4 hops), EU AI Act high-risk scope classification.' That is a concrete verb-plus-resource with the checks it performs. It does not, however, explicitly differentiate itself from close siblings such as verify_acdc_delegation_chain, check_agent_token_scope, or validate_agent_obo_mandate, which an agent picking among many attestation tools needs.

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 through pipeline metadata: 'Consumes upstream artifacts from art-01-ap2-mandate-chain-validator...' and 'Output feeds: art-02-agent-spend-policy-simulator...' tells an agent where this sits in a chain but not when to prefer it over alternatives. There is no explicit when-to-use or when-not guidance, and no statement of prerequisites for the credential being attested.

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