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

With no annotations supplied, the description carries the full burden and does so: it discloses billing mechanics (100 free recipients/month, 20 credits = $0.002 per recipient, x402 minimum $0.01 with unused balance retained as credit), daily recipient caps, the reply-only restriction and its anti-spam rationale, and the attachment surcharge. This is exactly the kind of cost, quota, and permission context an agent cannot infer from an unannotated schema.

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 action and the sending identity are front-loaded, followed by the monetization ladder and then limits and next steps in a logical order. The payment parenthetical is dense but each clause carries real operational meaning; only the stacked pricing details risk slowing an agent scanning for the permission rule.

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 10-parameter, unannotated, no-output-schema mutation tool the description is unusually complete: it covers cost, quotas, eligibility, and follow-up calls, and the attachment field itself documents the 64 KB MCP payload limit with a REST fallback. What it omits is whether read_token must be supplied at call time and what the call returns (e.g., a message id to pair with in_reply_to later).

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 schema already defines every field and the baseline is 3; the description goes further by explaining what account_key does economically (pay from an account with credits) and how payment-related retries work via _meta["x402/payment"]. It does not clarify when read_token is needed versus optional, which is the one gap given it is absent from the required list.

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 first sentence names a specific verb and resource and pins down the sending identity: an email sent from this inbox's own @getcourier.dev address. That scope statement also separates it from siblings like create_inbox or list_messages, so an agent knows exactly what this tool produces without opening the 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?

It lays out a full decision tree: free tier is reply-only, and to reach arbitrary recipients you either pass an account_key with credits, pay per call via x402 (with the exact retry mechanism), or verify an owner with verify_owner. It also states hard caps (50 distinct recipients/day), a prohibition on bulk/unsolicited mail, and a concrete next step (wait_for_code or list_messages), leaving little to inference.

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