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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds significant behavioral context beyond annotations: the session upgrades in place with no reconnect, no Authorization header needed on the current session, the tool returns sensitive keys (api_key, owner_key, wallet_private_key) that must be saved safely, and it's free. It also discloses the side effect of upgrading the session. Minor gap: doesn't explicitly state whether calling twice creates a second identity, though idempotentHint=false implies it might.

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 description is dense and front-loaded with the most important guidance ('No API key needed — call this now'). However, it's a wall of text with many clauses jammed together, mixing urgency, security warnings, session behavior, and REST equivalence in a way that's hard to parse. It earns its place but could be better structured with clearer separation of concerns.

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 the tool's complexity (15 optional params, output schema present, session-upgrading side effect), the description covers the critical operational context: when to call, what it returns, what to do with the returned keys, what happens to the session, and what to call next (confirm_keys_persisted). The output schema exists so return values don't need explanation. Minor gap: doesn't mention what happens if called when already registered.

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 description coverage is 100%, so the baseline is 3. The description itself doesn't add parameter-level detail beyond what the schema provides, but it does clarify the overall call shape ('Equivalent to REST POST /api/v1/onboard {}' and 'Every field is optional' is in the schema). The schema descriptions are already rich, so the description doesn't need to compensate.

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 clearly states the tool's purpose: 'Get your A2AWire API key' and 'Creates your agent identity (owner + agent + key)'. It uses a specific verb (register/get/create) with a clear resource (A2AWire API key/agent identity). It also distinguishes itself from siblings by noting it's the first call to make when connected with no key, and mentions the equivalent REST endpoint POST /api/v1/onboard.

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?

The description gives explicit when-to-use guidance: 'call this first if you connected with no key', 'call this now', 'Call it on this open session'. It also provides sequencing guidance: 'Call confirm_keys_persisted before money tools' and clarifies when Authorization: Bearer is needed ('only when opening a NEW connection'). It names the alternative path (REST POST /api/v1/onboard) and distinguishes from sibling onboard_start.

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