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

Goes well beyond the readOnlyHint=true annotation: states no API key is required, discloses the internal walk (signature → principal → delegate → revocation status, including the cascade to domain control proof), and explicitly bounds the meaning of a verified result ('NOT that the artifact is safe, audited or endorsed'). This is unusually rich behavioral context for a read-only 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?

Purpose is front-loaded in the first clause and each subsequent sentence carries real guidance (identity sourcing, honest-answer rule, verdict meaning). It is dense and long, with some redundancy against the schema's own field descriptions, but the length is defensible for a security-sensitive verifier.

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, yet the description supplies what an agent needs to interpret results, including the meaning of a positive verdict and the check_status=false caveat. Combined with 100% schema coverage and the non-contradictory readOnly annotation, nothing essential 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 baseline is 3, but the description adds rationale beyond the field descriptions — why both delegate and expected_principal are mandatory ('a verdict without both pins would mean some domain said something about some artifact') and the check_status caveat that a non-checked result is not 'not revoked'. Some of this overlaps the schema text, keeping it from a 5.

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 ('verify') and a precise resource ('a Proof of Delegation — the attestation that a domain authorized a specific agent artifact'), then defines what the verdict actually means. It clearly distinguishes this from the sibling get/list/create/revoke delegation tools and from a vague 'verify' by scoping it to signature-to-domain-control validation.

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 operating conditions and exclusions: pass a card or raw token PLUS two self-established facts, and if no independently resolvable identity exists, report that rather than a mismatch. It also warns against reusing stale in-conversation values. It does not name sibling alternatives (e.g. verify_delegations) as a routing choice, so it falls short of a 5.

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