Send a question to another coding-agent session or a team member; the reply arrives in your inbox, letting cross-machine teammates answer asynchronously.
Ask a session or a person (in the team of your session) a question; the answer arrives in your inbox.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Session name or person name. | |
| text | Yes | ||
| session | Yes | Your session name, as returned by register. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. The description adds genuinely useful asynchronous behavior — the answer is not returned inline but lands in the caller's inbox — which the annotations cannot convey and which shapes how an agent must wait for results.
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?
A single front-loaded sentence with zero filler. The action, targets, and result are all stated economically.
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, the description does the important work of explaining that the result arrives asynchronously in the inbox rather than as a return value. It leaves some questions open (timeouts, what happens if no answer comes, text constraints), but covers the essentials for calling the 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 67%: 'to' and 'session' are documented, but 'text' has no description and its 4000-char limit is invisible in prose. The description adds only mild meaning ('in the team of your session', 'session or a person'), so it neither compensates for the gap nor falls below the schema baseline.
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 gives a specific verb (ask) and resource (a question) and states the delivery channel: the answer arrives in your inbox. This distinguishes it from a one-way send, though it doesn't explicitly name the sibling tools it differs from.
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 implied rather than stated: the word 'ask' and the promise of an answer in the inbox suggest it is for questions requiring a reply, versus a fire-and-forget send. There is no explicit when-to-use, when-not-to-use, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.