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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: deterministic ordering (most recent first) and, importantly, that tapped interactive-element messages expose tapped_action {kind, payload, title} so the agent should read the payload there rather than parse platform_data. That is a non-obvious behavioral detail an agent would otherwise miss.

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?

Two sentences, front-loaded with purpose and ordering before the filter detail. The second sentence is dense with a long parenthetical enumeration of interactive element types, but each clause carries actionable information rather than 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?

There is no output schema, so the description carries some return-shape burden and does address it by explaining the tapped_action structure. With 100% parameter coverage and annotation-declared safety, the only mild omission is pagination behavior, which is largely covered by the schema's page/per_page descriptions.

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 all five parameters (page, status, chat_id, per_page, direction) are already documented in the schema; the description only echoes direction and status. Baseline 3 applies. The tapped_action detail is about return data, not parameters, so it does not raise this dimension.

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?

States a specific verb and resource ("List messages in a chat") plus a result ordering ("most recent first"), which implicitly separates it from the singular dm_message_get and the write-oriented dm_message_send. It stops short of explicitly naming an alternative sibling, so it lands at 4 rather than 5.

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 says filters are optional and which two dimensions can be filtered (direction, status), which is implied usage guidance. But there is no explicit when-to-use-this vs dm_message_get or dm_chats_list, and no stated prerequisites for the chat_id. Adequate but with a clear gap.

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