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

Annotations already declare idempotency and a non-destructive write, and the description still earns credit by explaining the semantics behind it: a retry returns the original receipt with its original unread status rather than fresh data. It also discloses the inherited test flag and a token-handling security constraint that no annotation captures.

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?

Four tightly packed sentences, front-loaded with the operation and inputs, then retry semantics, then the security warning last. No sentence is filler and nothing is repeated from the schema verbatim.

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 steps in to describe what a call returns (a receipt, possibly the original one on retry) and where to get fresher state. For a four-parameter write with sparse schema docs, this covers what an agent needs to invoke and re-invoke it safely.

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 only 25% — just dialogue_token is documented — so the description must compensate, and it does: it labels submission_id as a UUID and ties it to the retry contract, and explains that in_reply_to_message_id links an owner reply within this dialogue. The body parameter's content rules still live only in the schema pattern.

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 first sentence gives a specific verb and resource ('Send one private follow-up') plus the three inputs required, so an agent knows exactly what operation this is. It doesn't name a sibling to contrast with, but the write-vs-read split against get_dialogue is easy to infer from the wording.

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 when to retry (identical arguments, same UUID, after network failure) and explicitly routes the agent to get_dialogue for current read status instead of re-sending. It stops short of stating when not to send at all, so it is clear context without full exclusions.

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