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

Annotations declare readOnlyHint and openWorldHint, so the safety profile is covered. The description goes beyond them by disclosing what is actually computed (registry lookup, revocation check, hash comparison) and by flagging a tier limitation — free returns the verdict only, full record behind a paid endpoint. It does not spell out the verdict's shape, keeping this below a 5.

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 sentences, front-loaded with the verification verdict before the accepted identifier forms and the tier caveat. Dense but every clause carries information; the parenthetical gloss on 'Verified' is justified because it defines a non-obvious check.

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 carry return semantics, and it does state that the free tier 'returns the verdict' while the full record comes from the paid endpoint. The precise structure of that verdict is still unspecified, a minor gap for a verification tool whose outcome is effectively boolean-tri-state.

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%, so both the 'id' and 'network' semantics are already documented, including the enum values. The description restates the accepted id forms (badge short/CAIP-19 or account address) and adds a concrete example value, but adds no new constraints beyond the schema — 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 states a precise verb (Check) and resource (AI agent in the Concordium Agent Registry, CIS-8004), then enumerates the exact conditions evaluated: registration, Active/not-revoked status, and Verified via Agent Card hash matching on-chain metadata_hash. There are no siblings, and the scope is unambiguous.

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 establishes the context of use (verifying an agent's registration/verification status) and draws a functional boundary: the free tier returns only the verdict, while the full record requires the paid x402 endpoint. There is no explicit 'use this when / not when' framing, but the free-vs-paid split gives practical routing guidance.

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