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

With no annotations provided, the description carries the full behavioral burden. It discloses that the tool creates a real card, returns its URL, enforces a 3-demo limit per sender, and that demo cards do not count against the 5 free cards. It does not explicitly state whether a real card counts against the 5 free cards or whether an email is actually delivered, but the disclosure is still strong for an unannotated tool.

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 concise and front-loaded with the core purpose, followed by concrete usage rules and the send_card routing. The 'TRY IT' and 'zero decisions' phrasing is lightly promotional, but every sentence contributes useful information and nothing is redundant or bloated.

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 simple tool with three optional parameters and no output schema, the description covers the key return value (URL), the demo vs real behavior, quota implications, and the intended workflow transfer to send_card. Minor gaps remain around exact real-card quota counting and whether a real card triggers an email delivery, but these are not critical 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?

Schema description coverage is 0%, so the description must add meaning beyond the bare property names. It does clarify that every argument is optional and explains the semantic difference of recipient_email (empty = demo, populated = real card). However, it does not explain occasion or sender_name beyond what their names and defaults already imply.

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 states a specific action and resource: 'creates a real, live Dear Human card and returns its URL'. It also distinguishes itself from send_card by saying 'Then use send_card to say what you actually mean', which prevents confusion with the primary sending tool.

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 clearly frames when to use this tool ('TRY IT', 'zero decisions') and gives concrete usage conditions: leave recipient_email empty for a demo or provide it to make a real card. It names send_card as the alternative for actual messaging. It does not explicitly mention preview_card or other siblings, but the guidance is sufficient for the main decision.

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