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

With no annotations provided, the description carries the full burden and does so admirably. It discloses that the operation is paid via x402, explains the two-step payment mechanism, imposes size limits and upload behavior, reveals encryption requirements based on recipient settings, and describes the receipt_vault product variant (flat-priced, 365-day storage). No annotations exist to contradict these statements.

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 compact (four sentences) yet information-dense. It is front-loaded with the primary purpose, then systematically covers payment, size modes, encryption, and product variants. Every sentence earns its place; there is no redundancy or filler.

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 tool with 12 parameters and no output schema, this description covers all critical operational aspects: authentication/payment flow, size constraints, upload mechanism, encryption condition, and special product behavior. The remaining parameters (tag, content_type, ttl_days, producer, idempotency_key) are either self-explanatory or have schema descriptions, so the overall context is complete for correct 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?

Even with 67% schema description coverage, the description adds crucial inter-parameter semantics that the schema alone lacks. It explains how payment_b64 relates to the initial price-request call, how body_b64/body_upload/size_bytes work together for file size handling, what encrypted:true signifies in the context of sealed-box ciphertext, and the special meaning of product:'receipt_vault'. This goes well beyond repeating field types.

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 opens with a specific verb and resource: 'Deliver data to any wallet-addressed mailbox.' It clearly distinguishes this from sibling tools (all of which are read/lookup operations) by explaining it is the send/payment tool. The mention of 'your own future self's' mailbox adds nuance, and the title 'Send a message to a wallet address (paid)' reinforces the action.

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 provides explicit usage flow: 'call without payment_b64 to get the price and accepts[] requirements, sign an EIP-3009 USDC authorization, retry with payment_b64.' It also lays out conditions for choosing inline vs. upload mode (≤32KB vs larger) and when encryption is required (if recipient registered require_e2e). This goes far beyond simply saying 'use this to send' and gives concrete procedural guidance.

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