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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, yet the description adds genuinely important context beyond them: the private key is returned in the result, is never stored, and browser-side generation happens locally without transmission. That security-relevant disclosure is what an agent needs before echoing key material; only the action-specific behavior (which fields are consumed per mode) is unstated.

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 short sentences, operation and supported formats front-loaded, security caveat immediately after. No filler and nothing redundant with the schema.

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?

An output schema exists, so return-value documentation is unnecessary. Combined with annotations, the description covers safety and data-handling adequately; the only gap is action-specific parameter requirements, which is a modest omission for a five-parameter tool.

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 40% and five parameters exist, so the description must compensate. It names the algorithm families behind the alg enum and both serialization formats, but says nothing about modulusLength, the default ES256, or which parameters each action requires — the schema's own descriptions carry most of that load.

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 (generate, convert) and resource (RSA/EC/Ed25519 key pair in PEM and JWK) with the supported algorithm families and both output formats named. No sibling tool in the list does keypair generation, so it is trivially distinguishable.

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?

The description implies the two modes of use ('generate ... or convert between PEM and JWK'), which maps onto the action enum, but never states when to pick generate vs to_jwk vs to_pem, nor prerequisites such as supplying jwk for to_pem. Usage is inferable but not spelled out.

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