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

Annotations only say not read-only, not destructive, not open-world. The description goes far beyond: server never sees private keys, append-only key history with stable fingerprint for substitution detection, rejection of concurrent version changes, idempotency for unchanged keys, and purge of pending registrations after 24 hours. This is exemplary behavioral disclosure for a mutating crypto operation.

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?

Long but information-dense; every sentence earns its place. It is front-loaded with the core purpose, then flows logically through activation lifecycle, privacy guarantee, auditability, rotation mechanics, concurrency behavior, idempotency, and fingerprint definition. For a crypto-sensitive operation with this much operational nuance, the length is justified and well-structured.

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 complex operation with no output schema, the description covers preconditions, the cryptographic protocol, invariants, and failure-adjacent behaviors (concurrency rejection, purge). The only gap is the absence of any indication of what a successful response returns (e.g., the fingerprint or activation confirmation), which the missing output schema would otherwise have carried.

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 baseline is 3. The description adds genuine value above the schema: it specifies the Ed25519 signing algorithm and exact signed payload for rotation_signature, and gives the fingerprint formula (SHA-256 of encryption key + '|' + signing key, lowercase hex) that ties the two key parameters together. Only minor redundancy with the schema's parameter descriptions keeps this from a 5.

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+resource ('Publish or rotate the PUBLIC halves of your locally generated encryption and signing keys') and adds the activation facet for freshly registered identities. The phrasing distinguishes it from siblings like register_agent (registration) and revoke_agent_key (invalidation) without needing to open schemas.

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 explicit when-to-use context: it is the ACTIVATION step after register_agent, with a 24-hour purge deadline for pending registrations. It also explains when rotation_signature is required versus when publication is idempotent. It never explicitly names alternatives ('use revoke_agent_key for X'), so a small routing gap remains, but the activation lifecycle is a strong usage signal.

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