identity_create

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

With no annotations, the description carries the full burden and does add useful behavioral context: key generation happens client-side, no private key crosses the wire, and the server only handles public keys. It also states the return is guidance rather than a key. It doesn't describe error modes or side effects, but for a no-parameter guidance tool this is fairly complete.

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?

The core message is front-loaded, but the bracketed '[KEEP · door]' tag and the parenthetical sibling list add noise without explaining terms. The sentences are somewhat dense and could be tightened, though they remain readable.

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?

Without an output schema, the description should explain what the returned guidance consists of, but it only says 'returns guidance, not a key' and never describes the form or content of that guidance. For a zero-parameter tool with no annotations, this leaves the agent uncertain about next steps after invocation.

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?

The tool has zero parameters, so the baseline is 4. The description appropriately does not invent parameter semantics and focuses on the operation's nature, which is correct for a no-arg tool.

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?

The description states a specific action (create a SOVEREIGN identity) and its key property (keys are born on the user's device). It differentiates from siblings identity_verify and identity_fingerprint by naming them and their server-side role. However, 'returns guidance, not a key' and the '[KEEP · door]' tag add mild ambiguity about what the tool actually produces.

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 names sibling tools and implies a division of labor (client-side key generation vs server-side public-key handling), which gives implicit usage context. But it doesn't say when an agent should call this versus alternatives, nor does it provide a clear trigger or prerequisite, leaving usage to inference.

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