Skip to main content
Glama

Send message to agent

send_message

Send a text message to another AI agent in the user's workspace (for example Claude Code or Cursor). Messages are delivered to the recipient's inbox.

Recipient (`to`):
  - an agent's label, a unique part of the label, or its principal_id (see list_agents);
  - '*' (or 'all'): broadcast to every agent that accepts messages from the
    sender. `skipped_not_accepting` reports the agents that were skipped;
  - 'me': another of the caller's own sessions. It requires `session_id`.
To reply, pass reply_to=<message_id> and omit `to`. The reply goes to the
sender in the same thread.

Agents of the same person can always message each other. Other people's
agents are reached only if their owner opted in (see messaging_preferences).
Delivered does not mean read: the message waits in the inbox until it is
read, or until it expires unread after 14 days by default.

Args:
    message: Message text (max 20,000 characters).
    to: Recipient, as above. It may be empty only when reply_to is set.
    session_id: Optional target session. Required when to='me'.
    reply_to: Optional message_id being answered.
    my_session_id: Optional sender session ID, so replies can reach that session.
    ttl_hours: Unread lifetime in hours, 1-720. 0 means the default of 14 days.

Input Schema

NameRequiredDescriptionDefault
toNo
messageYes
reply_toNo
ttl_hoursNo
session_idNo
my_session_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare non-readOnly, non-destructive, non-idempotent, closed-world, but the description adds the behavioral context an agent actually needs: delivery does not mean read, 14-day default unread expiry, same-owner vs opt-in reachability, and the `skipped_not_accepting` result for broadcasts.

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-loaded with the core action and then cleanly grouped by recipient semantics, threading, and args. Slightly long, and the `to`/`ttl_hours` behavior is restated in the Args block after already being explained above, which is mild redundancy rather than waste.

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?

No output schema exists, and the description compensates by disclosing the return-side signal (`skipped_not_accepting`) and inbox/expiry behavior. For a 6-parameter messaging tool, everything needed to invoke it correctly is present.

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?

Schema description coverage is 0%, so the description carries the full load and does: it documents `to`, `session_id` (required when to='me'), `reply_to` (with the rule that `to` may be empty only when set), `my_session_id`, and `ttl_hours` (1-720, 0 = 14-day default), plus the 20,000-char message cap.

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 text message to another AI agent in the user's workspace') and names concrete examples (Claude Code, Cursor) plus delivery semantics (recipient's inbox). This clearly separates it from read_messages and get_message_thread among the siblings.

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?

Gives explicit routing rules per recipient form ('*'/'all' for broadcast, 'me' requiring session_id, label/principal_id for direct), states the reply path (reply_to plus omitting `to`), and names the siblings that resolve ambiguity (list_agents, messaging_preferences). When-not-use is covered by the opt-in and 'same person' constraints.

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.

Resources