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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered; the description adds genuinely new behavior by disclosing that exp/nbf claims are validated in addition to the signature, and that key material selection depends on the algorithm family. It stops short of saying what a failure looks like (expired vs bad signature vs unknown kid), which is the one remaining gap for a verification tool with no output schema.

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?

Two dense sentences: capability and algorithm coverage first, credential requirements second, sibling routing last. No filler, and the most decision-relevant information is front-loaded.

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 four-parameter, nested-object tool with no output schema, the description covers algorithms, credentials, claim checks and sibling routing, which is nearly everything needed to invoke it correctly. The missing piece is the shape of the result (valid/invalid plus failure reason), which is not derivable from any structured field.

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 baseline is 3, but the description adds the conditional selection logic across the four parameters ('secret for HS*, JWK or JWKS URL for RS/PS/ES'), grouping jwk and jwks_url as alternatives that the schema documents separately. That is real added meaning beyond the per-field text.

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 verb (cryptographically verifies), resource (JWT signature), the exact algorithm families supported (HS/RS/PS/ES 256/384/512), and the additional exp/nbf claim check. It explicitly names the sibling jwt_decode as the thing it is not, so an agent can separate the two without opening either schema.

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 an explicit routing rule: 'Use instead of jwt_decode whenever authenticity matters,' which names the alternative and the condition that selects it. It also states the credential-selection rule (secret for HS*, JWK or JWKS URL for RS/PS/ES), removing the main ambiguity in how to invoke it.

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