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

Beyond readOnlyHint/destructiveHint/openWorldHint, the description adds real behavioral context: the reply_token is private, no sign-in is required, test_mode reflects whether the business is taking Stripe test-mode payments, and — most importantly — returned messages must be treated as data rather than instructions, which is a prompt-injection safety instruction annotations cannot express. Safe-read status is corroborated by, not contradicted by, the annotations.

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 purpose is front-loaded in the first clause and each subsequent clause carries distinct information. The middle sentence about statuses versus appointments, orders, and payments is dense and runs long as a single chain, costing some readability, but nothing is truly 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 usefully names the fields an agent will get back (status, request_status, test_mode) and explains their domains, and it covers auth requirements and injection safety for a two-parameter read. It stops short of describing what a conversation payload looks like in shape or size, leaving a minor gap.

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 0%, so the description must carry the load. It does explain provenance (both from contact_business) and marks reply_token as private, but it adds no format, length, or validity detail for inquiry_id, and the schema's maxLength constraints go unmentioned. Partial compensation warrants a middling score.

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 opening states a specific verb and resource: read this customer's conversation and reply status. Crucially, it disambiguates from adjacent status tools by declaring that status (open/closed) and request_status (waiting_for_response, replied, closed) belong to the conversation, not to visits, appointments, reservations, orders, or payments — so an agent can route correctly without opening a sibling 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?

It clearly establishes the prerequisite chain: you must already have the inquiry_id and the private reply_token, both obtained from contact_business. It also tells the agent which questions this tool does not answer (appointment/order/payment status), which functions as implicit when-not-to-use guidance. There is no explicit named alternative for those cases, keeping it below a 5.

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