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

No annotations are provided, so the description carries the full burden, and it discloses the security-critical behavior ('Never send a private key') plus the required payload shape and multi-party semantics (one signature is a claim, more begin to establish a matter). It does not describe return values, authorization requirements, or failure modes.

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 instruction and the inner/phase marker are front-loaded and dense with actionable content. The closing Deuteronomy reference is thematic rather than operational, but it does encode the multi-witness semantics, so it earns its place for a specialized audience.

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?

With no annotations, no output schema, and a 2-param nested payload, the description supplies the flow, the security constraint, and the attestation structure an agent needs. It is nearly complete for the call itself; only the response behavior is left unspecified.

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 only 50% (content_hash has no description), but the description compensates: it explains that content_hash is the value returned from the unsigned phase and that attestation is the locally built dict of shape {alg, over, content_hash, pubkey, sig}. This meaningfully extends what the schema provides.

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 ('Bind your identity to a record you already hold') and frames it as phase 2 of a named flow. It also names the phase-1 siblings (badges_issue, study_export, group_contribute) it follows, so an agent can place it relative to them. It does not, however, contrast with the closest sibling (self_attest) or witnesses.

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 a concrete workflow: do the thing unsigned, take the returned content_hash, sign it locally, submit only the attestation. It names the alternative tools for the unsigned phase and states the constraint 'Never send a private key.' It stops short of explicit when-not-to-use or a direct contrast with self_attest/witnesses.

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