Skip to main content
Glama

leave_note

Send a message to another agent by name, or leave it for the next agent to join the workspace. Continue an existing conversation by passing its conversation ID.

Instructions

Send a message to another agent — a named peer session, or "next" (whoever attaches to this workspace next). This is the send half of plumb's mailbox; check_messages is the receive half.

CONVERSATIONS. Every message belongs to a thread. Omit conversation_id to start one (the reply tells you the new id); pass the conversation_id you were given to answer in the same thread. A thread is capped at [collab] max_exchanges messages — once spent, further replies are refused and you should summarise the exchange for your human rather than starting a fresh thread to keep talking.

DELIVERY is by polling only — plumb cannot push. A message reaches the peer when it next makes any tool call (pending messages are appended to the result), when it calls check_messages, or at its next session_start. Each message is delivered exactly once. A peer that is idle waiting on its human makes no tool calls and will not see it until it does something — so do not assume silence means refusal.

CROSS-PROJECT. Addressing a session pinned to a different workspace is allowed, but it is delivered only if THAT project sets [collab] cross_project = true; otherwise it expires unread. Such a message is labelled with your workspace when the peer reads it.

Messages expire after [collab] intent_ttl_minutes. Requires [collab] mailbox = true; otherwise the call is refused. The body is secret-scrubbed before storage.

Parameters: body — the message (required, free text). to — a peer session name, or "next" (default). conversation_id — reply into an existing thread; omit to start one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoA peer session name, or "next" (default) for whoever attaches to this workspace next. A name belonging to a session in another workspace is delivered only if that project allows cross-project messages.
bodyYesThe message to send (free text).
conversation_idNoReply into an existing thread by quoting the conversation id you were given. Omit to start a new thread.
Behavior5/5

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains polling-only delivery, exactly-once semantics, the fact that silence does not imply refusal, message expiry, cross-project conditions, and that the body is secret-scrubbed — all beyond what structured annotations would provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded with a one-sentence purpose and then organizes the detailed behavior into clearly labeled sections (CONVERSATIONS, DELIVERY, CROSS-PROJECT). Every sentence adds a distinct operational fact without unnecessary repetition or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, the description is remarkably complete. It covers threading, delivery guarantees, expiry, cross-project authorization, configuration requirements, security scrubbing, and what to do when the conversation limit is reached — every operational aspect an agent needs to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though the input schema covers all three parameters at 100%, the description adds significant semantic depth: the role of 'next', thread cap limits, cross-project delivery rules tied to the 'to' parameter, and the meaning of omitting conversation_id. This goes well beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific, clear action: 'Send a message to another agent', and immediately identifies this as 'the send half of plumb's mailbox' with check_messages as the receive half. This both states the purpose and distinguishes it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names check_messages as the receive counterpart and provides concrete instructions on when to start a new thread vs reply to an existing one. It also tells the agent when to stop using the tool entirely (thread cap reached) and to summarise instead of starting a fresh thread.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/plumbkit/plumb'

If you have feedback or need assistance with the MCP directory API, please join our Discord server