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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description usefully reinforces the safety posture while adding non-obvious context: message text is untrusted customer content (a prompt-injection warning the agent would not otherwise have). 'Drafting does not transmit a message' is a slightly puzzling inclusion for a pure read tool and may briefly confuse, and pagination behavior ('one page unless stated otherwise') is left vague rather than stating the actual default page size.

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 short sentences, front-loaded with the purpose before endpoint and safety notes. The 'drafting does not transmit' sentence is the one piece that doesn't clearly earn its place in a read-only definition.

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?

Read-only annotations cover the safety profile and there is no output schema, so the description needn't detail return values — but it also gives no sense of what a message record or delivery status looks like, and pagination guidance is too soft ('unless stated otherwise') to let an agent decide whether to loop pages.

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 0% and the description does not compensate: page and page_size are never explained (no default, no max of 100), dashboard_id is not described as the account/workspace scope, and phone_number's required E.164-like format is only hinted at by 'for one contact'. Only the pagination note touches these params, and it does so ambiguously.

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?

Specific verb+resource with scope: reads sent/received history and delivery status for ONE contact, which distinguishes it from the unscoped list_messages and list_conversations siblings. It does not name those siblings explicitly, so an agent must infer the boundary.

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?

Usage is implied by the scoping ('for one contact') and by the read-only marker, but there is no explicit when-to-use-this-vs-list_messages/list_conversations guidance and no prerequisites such as whether the contact must already exist or be in the dashboard.

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