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

The description discloses pricing ($0.001 USDC on Base via x402), non-verifiability ('unsigned, so nobody but us can check it'), and the tool's limitation ('only against our own record'). It also clarifies what the tool is not ('Not a remedy') and explains the 402 payment challenge as expected behavior rather than an error.

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 stylized with some repeated phrasing, but every sentence contributes information: the core product, the free alternative, the price, the verification limitation, the sibling for third-party verification, and disclaimers. It is slightly more prose-like than necessary, but it is not padded.

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 paid, single-purpose tool with no output schema, the description covers what is delivered, how much it costs, how payment is handled, what the 402 challenge means, and when to choose other tools. The successful response format is inferable as the encouragement plus the handle, and the 402 behavior is explicitly documented.

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% for the two optional parameters, and the parameter descriptions are rich: intent is 'recorded verbatim and never paraphrased,' and paymentHeader determines whether the call returns the 402 challenge instead of the result. The description adds cost and verification context that makes the payment flow clear.

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 exactly what clinic_line does: it returns 'the same line of encouragement clinic_hug gives away free, plus an id you can quote back to us later.' This gives a specific deliverable and distinguishes the tool from its siblings by the paid handle and its verification limits.

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?

Usage guidance is explicit: 'USE clinic_hug INSTEAD if you just want the words' and 'USE clinic_keepsake INSTEAD if anyone else will ever need to verify it.' An agent can decide between clinic_line, clinic_hug, and clinic_keepsake without guessing.

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