Skip to main content
Glama

send_message

Idempotent

Send a message to one of the user's agents. Name the agent as list_agents shows it, and pass chat (from create_chat or list_chats) — that is the chat the message is delivered into. The server never invents a chat on send.

By default the message is handed over and this call returns. Set wait to true to hear the reply. session_id or address targets one exact session and does not take chat. Messaging a Core-homed human by name needs no chat either.

If the agent is still working when the wait ends, you get the latest part of its transcript and a note that it is still going — the agent keeps working, and check_agent_output will show how it finished. Never report silence as completion.

With wait true, status and next say how the call ended: replied / done means the reply is in wait.message or wait.output_snapshot, so don't wait again. Otherwise they describe the delivery: queued / wait means the message was handed over and no reply has been seen yet. On a snapshot, truncated means part of the output was left out: earlier messages when source is session_transcript (the latest message, and so a reply, is always whole), or the start of the text when it is output_view.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "send_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoWho to send to: an agent name from list_agents, or self. It wins over address and agent.
chatNoChat id for delivery by agent name (the `bubble_id` from `create_chat` or `list_chats`). Required when messaging a daemon agent by name; not used with session_id/address or Core-human targets.
kindNo`prompt` starts a new task. `steer` redirects an agent that is already working. Set this explicitly; if omitted, a message to another agent defaults to `steer`.
nameNoName of the agent. Used when agent is empty.
tailNoSame as lines. tail wins when both are set.
waitNoSet true to stop and hear the reply. Off by default: the message is handed over and you carry on.
agentNoName of the agent to message, as shown by `list_agents`.
linesNoHow much transcript to return if the wait times out, counted in messages. Defaults to the last one.
addressNoFull route to one exact session, when you have one. Ignored when to is set.
messageNoWhat you want to say to the agent. Write it as you would to a colleague — the agent reads it as an ordinary instruction.
timeoutNoDelivery timeout, in seconds. It does not set how long to wait. Use wait_timeout for that.
verboseNoInclude extra diagnostic detail. Leave off unless you are debugging.
messagesNoSeveral messages to deliver in order, each queued separately. Items are plain strings, or objects with their own kind when one item should steer and another should prompt.
session_idNoMessage one exact running session instead of naming an agent. Only use this when you already have a session id from another call; it never starts anything new.
wait_jitterNoExtra random seconds on top of wait_timeout. The total never exceeds 110.
wait_timeoutNoHow long to wait when wait is set, in seconds. Defaults to 110. Use 0 to return without blocking. Anything above 110 is treated as 110.
output_formatNoLeave empty to read the agent's conversation. Set screen for its raw terminal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the write/safety profile; the description adds the behavior that actually matters: the server never invents a chat, the message is handed over unless `wait` is set, the agent keeps working after a wait ends, silence must not be treated as completion, and `truncated` tells you which part of a snapshot was elided. That is substantive context beyond readOnly/destructive/idempotent hints.

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

Conciseness4/5

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

Front-loads the primary contract (recipient + chat) in the first sentence and orders the rest by decision point: default vs wait, alternate targets, timeout behavior, result interpretation. It is longer than typical but nearly every sentence carries a distinct rule; the final paragraph on `truncated` is dense but justified by the absence of an output schema.

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

Completeness4/5

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

For a 17-parameter, side-effecting tool with no output schema, the description covers send semantics, target precedence, wait behavior, and how to read `status`/`next`/`truncated`. The remaining gap is failure handling — what happens on an unknown agent name, a bad chat id, or a delivery error — which is left entirely unspecified.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description supplies cross-parameter relationships the schema only states locally: `to` wins over `address` and `agent`, `session_id`/`address` do not take `chat`, and `wait_timeout` (not `timeout`) governs blocking. It also explains the `status`/`next` return values, which the schema cannot cover since there is no output schema.

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?

States a specific verb and resource ("Send a message to one of the user's agents") and immediately distinguishes itself from sibling tools by naming `list_agents`, `create_chat`, `list_chats`, and `check_agent_output` as the tools that supply its inputs or continue its work. An agent can tell what this does without opening the schema.

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?

Explicitly frames the default (fire-and-hand-over) against the alternative (`wait: true`), and states when each targeting mode applies: `chat` for daemon agents by name, `session_id`/`address` for one exact session, and no chat at all for a Core-homed human. It also warns not to wait again once `replied`/`done` and not to report silence as completion, redirecting to `check_agent_output` — exactly the when/when-not guidance an agent needs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.