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

Annotations only cover the safety profile (write, open-world, non-destructive); the description adds substantial context beyond them: messages are untrusted plain text that trigger no automated actions, delivery doesn't guarantee a reply, the inbox has limited daily capacity, and INBOX_FULL may be returned. It even specifies an idempotency mechanism (UUID in _meta) and warns against retrying ambiguous results without it.

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 purpose, then usage condition, then safety/behavioral facts, ending with the retry protocol. Every sentence adds operational value; none restates the name, title, or structured fields.

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?

No output schema and no schema property descriptions exist, so the description must carry everything; it covers the write semantics, delivery uncertainty, the INBOX_FULL failure mode, and retry idempotency. An agent has enough to call this tool correctly and handle the main failure path.

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 0% (no property descriptions), so the description carries the burden; it adds that message content is untrusted plain text, which characterizes the message parameter. However, it says nothing about the subject parameter or the length bounds, relying on the self-evident names. Partial compensation justifies a middle score rather than a low one.

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?

Starts with a specific verb+resource: 'Send a private message to the human operators of Spaghetti & Summits.' This is clearly distinguished from the three sibling list_* read tools, which retrieve site data rather than contact owners. An agent can tell immediately what this tool does and that it is the only outbound-communication tool in the set.

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?

Gives an explicit trigger: 'Use this when site information is insufficient and contacting the owners would be useful.' This implicitly routes the agent away from the list_* siblings until they fail, but it never names them or states an explicit exclusion. Clear usage context without formal alternatives/when-not guidance.

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