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

Goes well past the annotations (readOnly/idempotent/non-destructive) by disclosing real behavioral edges: a not-found result when the id belongs to another number, and a retention window (1h default, up to 72h) after which content is empty with content_expired true. It also disambiguates `at` from the moving `status.at`, which prevents a common misread.

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?

Front-loaded with the core action, then broken into short scannable paragraphs that each address a real ambiguity. The `at` vs `status.at` discussion borders on output-schema territory, but it is short and prevents a concrete mistake.

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?

An output schema exists, so return shape need not be described, and the description still covers the operation's edge conditions: cross-number lookups fail, expired content returns empty with a flag, and timestamps have two distinct meanings. Nothing an agent needs before calling is missing.

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 100% and the schema already explains message_id format and that number_alias may be an alias or a stable `num_…` id. The description restates the stable `number_id`/`number_alias` pairing rather than adding new parameter meaning, so baseline 3 applies.

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 with scope ('Fetch one message with its full content, parties and mentions'), which implicitly separates it from list_messages and from the narrower get_message_status/get_message_receipts/get_message_reactions siblings. It stops short of naming those alternatives explicitly, so an agent must infer the split.

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 only implied by the scope statement ('one message', 'full content'); there is no explicit when-to-use or when-not-to-use guidance and no sibling is named as an alternative. The failure/retention notes are useful context but are behavioral facts rather than routing guidance.

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