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

Annotations only say it is a non-read-only, open-world, non-destructive, non-idempotent operation; the description supplies the real behavioral detail: nothing transmits on the first call, the preview+code handshake, that Avenbridge emails the contact with the user's address as reply-to and copies the user, and that answers return via status and answer_questions. The duplicate-suppression note ('same questions sent again within a day are not sent twice') adds a rate-limit-like behavior the annotations do not convey.

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 flow is front-loaded (preview first, then confirm), which is the right ordering for the reader. It is slightly dense and run-on in the back half, packing email routing and answer retrieval into one long sentence, but no sentence 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?

With no output schema, the description still explains what each call returns (a preview plus confirmation code) and how results come back later (status, then answer_questions). For a 5-parameter, open-world mutation with a two-phase handshake, that covers everything an agent needs to invoke it correctly.

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 80%, so the baseline is 3, but the description adds conditional logic the schema does not state: business_id (or business) is required only when the user has more than one business. It also frames 'confirm' as the code from the preview that must follow user agreement, which explains the sequencing semantics of that parameter.

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?

States a specific verb and resource: send questions to one business's contact person, with the two-step preview/confirm mechanism named up front. It explicitly positions itself against the sibling answer_questions, so an agent can distinguish the two without opening either 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?

Gives explicit when-to-use ('questions answer_questions could not answer'), the when-not of the first call ('Nothing is sent on the first call'), and the exact condition for the second call ('only if they agree, call again with the same business and confirm set to the code'). It also states the multi-business prerequisite for business_id/business, 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.