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

The description adds substantial behavior beyond the annotations: the two-phase preview/confirm handshake, that nothing is transmitted on the first call, that Avenbridge emails the contact with the user's email as reply-to and copies the user, and that the reply surfaces via `status`. However, it states that an identical request re-sent within a day is not sent twice, while annotations declare idempotentHint=false — a mild tension an agent could trip over. With annotations already covering safety and openness, the added context is good but this friction costs a point.

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?

Front-loaded with purpose and the call-vs-preview branch before the mechanics, and nearly every sentence carries operational weight. It is dense and on the long side, with one awkward double negative ('is not sent twice') that could be tighter, but nothing is 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 an open-world, multi-step mutation tool with no output schema, the description covers the confirmation workflow, delivery side effects, deduplication, and where the business's reply appears. An agent has everything needed to call it correctly on the first and second attempt.

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%, yet the description still adds semantics the schema lacks: `kind` must match a kind the business lists (with 'call' triggering a fundamentally different flow), `confirm` is the code from the preview and must be omitted on the first call, `details` should carry the checklist items, and `business`/`business_id` may be omitted when the user has one business.

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 concrete verb and resource ('Send a request to one business') and enumerates the request kinds, so its function is unmistakable. It cross-references list_my_businesses and status, but never distinguishes itself from the sibling ask_business, which sounds like it could serve a similar need — an agent must guess between the two.

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?

Explicit branching: when the business lists 'call', use kind call and the user books on the business's page; otherwise the first call only returns a preview and a confirmation code, and a second call with confirm is required. It also tells the agent to ask for checklist items before quote/sample requests, which is a concrete when-to-use rule rather than an inference.

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