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

With no annotations provided, the description carries the full behavioral burden and meets it: it discloses one-shot deterministic retrieval, the narrow scope ('drains ONLY the pinned rendezvous relay'), destructive side effects ('Mismatched DMs are deleted and NACK'd'), failure semantics, the security storage model (proof stored as a hash key; 'the MCP never stores the raw token itself'), and cost ('Free').

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 long, but every sentence earns its place: purpose first, the critical timing constraint bolded and front-loaded, then mechanism, side effects, failure mode, security, and cost. The density of unique information per sentence is high, with no filler or repetition.

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 high-complexity, destructive, one-shot tool with zero annotations, the description covers every context an agent needs: ordering precondition, side effects, failure behavior, return value, token custody responsibility, storage design, and cost. The output schema covers the exact return shape, so nothing material is missing.

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 adds flow-level meaning beyond the schema's per-parameter notes by explaining the provenance and lifecycle of dpop_token ('the value returned by request_npub_proof', must be remembered and passed 'on every subsequent paid tool call') and how patron_npub and dpop_token combine as the retrieval key. That contextual semantics is not present in the schema.

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 lead sentence 'Receive npub ownership confirmation from a patron' states a specific verb, resource, and actor, and the description immediately situates it in the npub-OWNERSHIP-PROOF flow, naming receive_credentials as the counterpart and request_npub_proof as the upstream step. This clearly distinguishes it from the ~80 sibling tools without needing to open any schema.

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?

Provides explicit when-to-call guidance, bolded: 'Call this only after the user confirms they have replied.' It names the flow partners (request_npub_proof produces the dpop_token; receive_credentials is the counterpart), states the failure consequence of premature calls, and explicitly forbids retries: 'Do NOT poll, loop, or retry.' This is the strongest possible usage guidance.

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