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

Annotations already declare this is a read-only, closed-world query, so the description doesn't need to cover safety. What it adds is domain behavior the annotations cannot: the specific 24-hour WhatsApp window, the existence of a closesAt boundary returned by the call, and the fact that the answer is one of three distinct reply modes. It stops short of describing the exact response shape, which it could have sketched in a few words.

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?

A single front-loaded sentence with no filler. The parenthetical about the 24-hour window and closesAt is dense but earns its place by explaining what 'inside the window' means. Slightly clause-heavy for one sentence but not wasteful.

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 carries the burden of explaining what comes back, and it does so at the level of the three reply states — enough for an agent to decide whether a team reply is possible. Parameters are covered by the schema. A brief note on which field carries the mode/closesAt in the response would close the remaining 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 100%, so both the brand and contact parameters are fully documented in the schema, including where to get the contact key. The description adds no parameter-level information beyond mentioning closesAt as a returned value rather than an input. Baseline 3 applies when the schema carries the parameter burden.

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 names the resource (the chat's reply window) and enumerates the three outcomes it reports: sent as typed inside the 24-hour window, only as a paid late message, or not at all yet. No sibling tool covers this question, so no competing tool needs to be distinguished. It is slightly oblique because it is phrased as a question rather than a verb+resource, but the intent is unmistakable.

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?

The implied use is clear from the wording — an agent checks this before drafting a team reply — but the description never states when to call it versus alternatives (e.g., read_chat, list_needs_you) or any prerequisite such as needing a contact key from list_chats. Usage must be inferred rather than read.

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