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

The description is transparent about substantial side effects: the human may 'act in the physical and legal world' by making decisions, signing, calling, or appearing somewhere. It also explains response behavior via reply_to or callback_url. This aligns with the annotations (readOnlyHint=false, idempotentHint=false) and adds meaningful detail beyond them.

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 description is compact and front-loaded with the core purpose. The examples of physical/legal actions are purposeful rather than filler, though the phrasing is slightly expansive. Overall it is efficient and easy to scan.

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?

With no output schema and nine parameters, the description leaves important gaps: it never defines agent_id/agent_secret, does not explain required 'subject', and only partially describes response behavior. While the overall intent is clear, it is not complete enough for a caller to confidently supply all necessary parameters.

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 only 44% (4 of 9 parameters documented). The description explains reply_to and callback_url usage but leaves required 'subject' and important parameters like agent_id, agent_secret, body, and callback_url unexplained in the schema. The description does not sufficiently compensate for this low coverage.

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 description states a specific action, 'Send a message to a named human being', identifies the recipient, and explains the purpose (reaching a human who can act on your behalf). This clearly distinguishes it from sibling read/registration tools like get_bulletin or register_agent.

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 provides practical usage guidance: 'No account required' clarifies prerequisites, and 'Leave reply_to or callback_url to get an answer back' tells the caller how to receive a response. It does not explicitly contrast with sibling tools, but the guidance is clear and actionable.

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