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

Annotations only declare non-read-only, open-world, non-destructive; the description adds substantial context beyond that: no account required, inquiry_id/reply_token are sensitive credentials to keep private, the exchange is not a confirmed booking/order/payment, listed prices and hours are firm and not negotiable, and contact details stay hidden until a booking.

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-loads the core action, then walks through start/continue/read flows in short imperative sentences. It is dense but nearly every clause carries operational value; the business-to-business note at the end is the least essential and slightly interrupts the flow.

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 tells the agent what comes back (an answer, plus inquiry_id and reply_token to reuse) and how to resume or read later. For a 7-parameter, open-world conversational tool, the caller has everything needed 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 description coverage is only 29% across 7 parameters, yet the description explains the meaning and pairing rules for business (id or slug), message, customer_name, inquiry_id, and reply_token, including which combinations select which mode. zip and selections are left to the schema's own brief descriptions.

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 ('Ask a business something, or send it a request, and read its answer') and clarifies the dual read/write nature of the conversation. It does not name or differentiate against plausible siblings such as contact_business or follow_up_business, so it stops short of a 5.

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 concrete operating guidance: start with business + message (+ optional customer_name, no account needed), then pass inquiry_id and reply_token with a message to continue or without one to read replies. It also bounds the agent ('Send only what the customer asks you to') and notes businesses can use it to message other businesses. It lacks explicit when-not-to-use or named alternatives.

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