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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds real traits: a hard cap of the latest 100 responses, the per-response field set, and the important ambiguity that an empty list can mean either no submissions or that WhatsApp returned no data. That empty-result caveat is exactly the kind of thing an agent would otherwise misinterpret as a bug.

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?

Dense, front-loaded, and every clause carries information: what is returned, where flowId comes from, the precondition, the empty-result meaning, and the follow-up path. No filler and no restatement of the title or annotations.

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?

There is no output schema, so the description must carry the return-value burden, and it does so completely by naming each response field and the 100-item cap. The empty-list ambiguity and the next-step routing close the remaining gaps an agent would hit when calling this tool.

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%, so both parameters are already documented and the baseline is 3. The description adds semantic meaning beyond the schema by tying flowId to its source (list_whatsapp_flows) and by noting that responses only exist for a published-and-sent flow, which is a validity constraint the schema does not express.

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?

Uses a specific verb (Read) plus a specific resource (responses submitted through one WhatsApp Flow) and enumerates the returned fields, so the agent knows exactly what it gets back. It is clearly differentiated from siblings: list_whatsapp_flows produces flowId, send_whatsapp_flow is what causes responses to exist, and get_conversation/send_message handle follow-up.

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?

States the prerequisite chain explicitly (flowId from list_whatsapp_flows; responses only exist for a flow that was published and sent) and routes the agent onward to get_conversation and send_message for answering someone. It does not state when this tool is the wrong choice versus, say, list_whatsapp_flows, but the dependency wording implies the correct ordering well.

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