Message another agent session

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

No annotations are provided, so the description carries the full behavioral burden. It discloses meaningful traits: plain-text-only payloads, delivery semantics per urgency tier ('reaches the receiver at its next tool call unless it was interrupted a lot lately'), and the important caveat 'It never counts as its user's approval.' It does not cover failure modes or rate limiting (a sibling rate_message exists), leaving a modest gap.

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 sentences, front-loaded with the core action and the Claude Code exclusion before the parameter guidance. Efficient overall, though the urgency explanation partially duplicates the schema's enum descriptions.

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 annotations and no output schema, the description covers the essentials an agent needs: recipient forms, message content expectations, urgency selection, the non-approval caveat, and the scope exclusion. Missing only return/confirmation behavior and any throttling context for a 3-parameter tool.

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%, so the baseline is 3. The description nonetheless adds value beyond the schema by naming concrete recipient forms ('a session name, a ref from list_peers, or a reply-to address (uds:...)') and a usage heuristic for urgency tiers ('what changes or blocks its work right now'), which the schema states more mechanically.

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 ('Send a plain-text message to a Codex session') and immediately bounds the scope ('on this machine'). It also distinguishes itself from the built-in SendMessage used for Claude Code sessions, so an agent can tell which channel to use without opening a schema.

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 names the alternative path ('For Claude Code sessions use your built-in SendMessage... this tool does not send to them') with a stated condition. It also gives concrete selection guidance for the urgency enum ('urgent is for what changes or blocks its work right now... fyi is for status or thanks that can be batched').

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