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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the no-signature read model, the x402/api-key auth options, and the important sandbox caveat that sandbox wallets are never `verified` and instead report sandbox:true and sandbox_verified. It lacks details on rate limits or failure modes, but the auth and sandbox semantics are genuinely useful.

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 tight sentences, front-loaded with the core question and only then moving to payment/auth and the sandbox edge case. No filler, though the second sentence is information-dense enough to slow parsing slightly.

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 two-parameter, no-output-schema query tool, the description covers the essential semantics: what is being checked, how to authenticate/pay, and how sandbox results differ. The only gap is the exact shape of a successful non-sandbox response, which is implied by the `verified` and `sandbox_verified` fields.

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, and the description goes beyond the schema by explaining api_key provenance (identity_get_test_key) and the IDENTITY_API_KEY environment-variable alternative, which the schema's 'Optional x-api-key' note does not mention.

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 question the tool answers — whether a wallet holds a valid, unexpired assertion — with a clear resource (wallet identity/assertion). An agent can distinguish it from sibling read tools like reputation_status or identity_jwks, though the description never explicitly contrasts with them.

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?

Explicitly describes the access paths: no signature required, pay via x402, or pass api_key obtained from the named sibling identity_get_test_key / IDENTITY_API_KEY env var. It does not say when to prefer this over reputation_status or reputation_query, so it stops short of full alternative routing.

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