verify_delegations

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

With no annotations provided, the description carries the full disclosure burden — and it delivers extensively: no cross-item state, no persistence, independence of results, no API key required, per-item checked_at timestamps, and a full outcome taxonomy (confirmed_valid, confirmed_invalid, no_claim_found, unconfirmed) complete with the critical warning to never treat unconfirmed as a bad verdict. This is far beyond minimal 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?

The description is long (~230 words) but every segment earns its place given the tool's complexity: four outcome semantics, a trust-boundary caveat, a timing subtlety, and an independence guarantee all need stating. The core purpose is front-loaded, and the density is purposeful rather than padded, though a few clauses could be tightened.

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 tool with no output schema and no annotations, the description is exceptionally complete: it covers the 50-item limit, the outcome vocabulary that substitutes for an output schema, per-item timing, authentication requirements, the trust boundary, and what the tool explicitly does NOT do. An agent has everything needed to decide when to call it and how to interpret results.

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 schema already documents the items array and its nested requirements thoroughly. The description adds genuine value on top: the 'card XOR token' relationship, the identity rule (delegate must be resolved afresh, never read from inside the artifact), and the batch-shape parallel to verify_delegation. It reinforces rather than repeats 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 opens with a specific verb-object pair ('Batch-verify up to 50 Proof of Delegation artifacts in one call') and immediately names the sibling it complements ('instead of one verify_delegation call per artifact'), making the tool's scope and identity unmistakable. The 'inventory half of the checker' framing sharpens the distinction from its namesake.

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 when-to-use guidance appears throughout: use it to re-check material you already trust en masse, not for discovery ('does NOT discover what you have installed and does NOT fetch anything on your behalf'). It names the alternative (verify_delegation) and the selection condition (batch vs single), and clarifies behavioral constraints like items being verified independently and revocation always being checked.

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