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

Annotations declare the mutation/idempotency/open-world profile, but the description adds what the annotations cannot: that a real notification is dispatched to a human-facing business channel, that a submission implies no pricing or booking commitment, and the exact idempotency-replay procedure for uncertain submissions. It also states a data-handling constraint (exclude medical, payment-card, authentication information) that complements destructiveHint=true.

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?

Five sentences, each carrying distinct load: trigger and effect, scope disclaimer, prerequisite, retry protocol, exclusion rule. The ordering is front-loaded and correct, but the semicolon-chained retry sentence and the dense final clause slightly burden fast parsing.

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 11-parameter, 6-required write tool with an output schema, the description covers the critical decision points: consent gate, prerequisite token, idempotent retry, and PII exclusions. It leaves silent the optional contact_* fields and how they interact with the business's notification destination, which is the main remaining ambiguity.

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 73%, and the description reinforces the two most failure-prone fields by explaining the idempotency_key reuse contract and the sanctioned content of 'details' (excluding sensitive data). It adds meaning beyond the schema for consent ('explicitly agrees') and context_token sourcing. It does not address the optional contact_name / contact_phone fields, which lack schema descriptions, so a small gap remains.

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 uses concrete verbs and objects: save the customer's service requirements and contact details, then notify the business via its configured email or opted-in SMS. It explicitly bounds the outcome as 'a business response, not a price commitment, booking or payment,' which separates it from confirm_booking, create_booking_payment_link, and get_quote without the agent needing to inspect siblings.

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 states the gating condition ('after the customer explicitly agrees'), the prerequisite source ('use context from request_service'), and the retry rule ('reuse the same idempotency_key AND details to check an uncertain submission; never automatically start a new request'). When-to-use, when-not-to-advance, and the recovery path are all explicit.

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