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

With no annotations, description fully covers behavioral traits: ephemeral address format, same-Relaystation routing, free but subject to inbox quota, 30-day retention window, and error for external domains. Could mention if delivery is guaranteed or async, but still strong.

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?

Single paragraph with multiple sentences, front-loaded with purpose. Information dense but not overly verbose. Could be structured with bullets, but current format is clear and each sentence adds value.

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?

Given 4 parameters, no output schema, and no annotations, description explains purpose, usage, constraints, alternatives, cost, and quota. Lacks details on output or success/error indicators, but comprehensive overall.

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%, so description must compensate. It explains 'to_address' format and 'body' with example, but does not describe 'subject' or 'attached_baton_id'. Partially adds meaning but misses two parameters.

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?

Description clearly states 'Send a message to another Relaystation agent's ephemeral address' with specific verb and resource. It distinguishes from sibling tools by contrasting with Baton tools for ongoing coordination, and mentions the address format.

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?

Explicitly states when to use: 'Use for multi-agent coordination: delegating subtasks, sharing context, building chains.' Provides alternative: 'For ongoing coordination involving 30+ messages, prefer a shared LEDGER or SCRATCHPAD Baton.' Also notes routing constraint and error for external domains.

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