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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'List' matches those hints. The description adds a useful data-model caveat about chat-scoped ID uniqueness, but it does not disclose other behavioral traits such as pagination or ordering. No contradiction with 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 first sentence is a crisp purpose statement, but the subsequent Chat ID and Message ID paragraphs duplicate the schema descriptions nearly verbatim. The 'Never pass' guidance is repeated and even includes a mutation-tool caveat that is irrelevant to this read-only lister. The content is structured, but it could be tightened significantly.

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?

The description provides the full ID acquisition chain and the chat-scoped uniqueness warning, so an agent knows exactly which parameters are required and how to obtain them. The absence of an output schema means the return shape is not described, but for a simple read-only list operation this is a minor gap given the strong annotations and parameter guidance.

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%, with both required parameters fully documented. The tool description mostly restates the schema's parameter text rather than adding new semantic detail, and account_id is documented only in the schema. Baseline 3 is appropriate because the schema already carries the parameter-semantics 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 opening sentence 'List detailed reactions on one exact message' names the action, resource, and scope precisely. The read-only verb distinguishes it from sibling mutation tools like message_add_reaction and message_remove_reaction without ambiguity.

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 description explains the required chat_id + message_id pairing and explicitly warns 'In V2 always keep chat_id together with message_id because providers may only guarantee uniqueness inside the chat.' It also tells the agent where to obtain each ID and what never to pass. It does not explicitly name an alternative tool, but the context is sufficient to avoid misuse.

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