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

With no annotations at all, the description carries the full burden, and it discloses only the crypto scheme and the consent gate. It is silent on whether the call is idempotent, what happens to an existing device identity, what permissions or session binding are needed, and what the caller receives — all material for a mutating identity-creation tool. The 'never a real-world identity' note is useful framing but does not fill those gaps.

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 tight sentences, front-loaded with the production qualifier and the consent prerequisite, with no filler. The phrase 'genesis from latest proof' is jargon-dense and slightly opaque, which keeps it from a 5.

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?

Given three parameters, a nested consent object, no output schema, and no annotations, the description should define the consent shape and the returned artifact. It only hints that a signed handle is produced. An agent could stumble on the consent object's required fields or on expected handle format.

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 33%, so the description must compensate and it partially does: 'signed handle' and 'scope.id === true' add meaning to the handle and consent parameters, and the session parameter is already documented in the schema. However, the nested consent object is a black box beyond a single required field, and the handle's expected format is never described.

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?

Names the resource (EDNA ID, production) and the concrete operation semantics: a device-bound identity backed by an ECDSA-P256 keypair with a signed handle, generated as a genesis from the latest proof. That is far more specific than a tautology. It does not distinguish itself from the closest sibling, edna_identity_create, so it stops short of a 5.

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 one hard precondition (consent.scope.id === true) and a scope caveat ('continuity proof — never a real-world identity'), which implies this is for pseudonymous machine identity rather than human verification. It never states when to prefer this over edna_identity_create or edna.id.feed, nor what happens if an ID already exists, so usage must be inferred.

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