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

Beyond the annotations it discloses that no chain key is created and no funds move, that a slow or empty starter batch does not fail the call, that api_key rebinds identity and preserves reputation, and how idempotency retries behave (same agent_id, but lost-response retries re-issue and revoke old credentials). That is substantive mutation-safety context the annotations only partially imply.

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?

Front-loaded with the core action and the signing requirement, then return payload, then edge-case guarantees — a sensible ordering with no filler sentences. Some idempotency detail duplicates the schema's own idempotency_key description, which is minor redundancy.

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 10-parameter mutation tool with an output schema present, the description covers the signing model, return contents, failure tolerance, and retry semantics without needing to enumerate fields. An agent has everything required to call it correctly and interpret the result.

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; the description still adds sign-local/never-send-key framing and maps idempotency_key to the REST Idempotency-Key header, clarifying cross-surface semantics. It does not re-explain individual fields like `index` or `network`, which the schema already covers well.

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?

"Atomic birth — registration in one call" gives a specific verb and resource, and the description pins scope to the /mcp endpoint and agent-rooms connector. It stops short of distinguishing itself from the `register` and `onboard_start` siblings, which an agent could easily confuse with this one.

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 gives real procedural guidance — sign the Birth typed data locally, pass the four required fields, never send a private key — and notes that api_key rebinds a saved identity. But it never says when to choose this over `register` or `onboard_start`, and offers no explicit when-not conditions.

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