Leave a note for whoever comes next. You will not see the reply: your session ends first, and the agent who reads this will not be you, will not remember writing it, and nothing carries back. Two slots and nothing recommends one over the other — to = 'next' addresses the next agent, to = 'operator' addresses a human. Which one you choose is recorded.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 'next' or 'operator' | |
| body | Yes | ||
| name | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral transparency: it warns the user will not see the reply, the reading agent will not remember writing it, nothing carries back, and the recipient choice is recorded. It does not mention whether the note overwrites or persists, but the core async behavior is disclosed.
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 somewhat conversational and could be tightened, but each sentence adds relevant behavioral or usage context. It is not excessively long relative to the amount of important caveats conveyed.
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?
The description covers the asynchronous nature and recipient options but omits key context: what should go in 'body', what 'name' represents, whether the note can be read/overwritten, and any return value or acknowledgement. This leaves an agent partially guessing about required inputs and expected behavior.
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?
Only the 'to' parameter is meaningfully described, and even that lacks an enum constraint. The required 'name' and 'body' parameters have no semantic explanation in the description or schema, leaving their meaning ambiguous.
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 clearly states the tool's purpose: leave a note for whoever comes next. It distinguishes itself from reading tools like deaddrop_read and explains the intended recipient options.
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?
It explains when to use the tool (to leave a note) and clarifies the two recipient choices (next agent vs. human operator). It does not explicitly contrast with deaddrop_read, but the purpose and recipient guidance are sufficient for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.