Skip to main content
Glama

Relay: send a message

send_message

Send a message on the person's behalf — to a friend, in an anonymous conversation, or in one of their group chats (conversationId g_, from relay_status.groups). Prefer send_to_conversation (it resolves names safely). It is labelled "via ". Stays within consent: friends, anonymous talks and group chats are the person's private life, so this saves a draft they send with one tap (you get a confirmUrl) — never sent in their name; off in their policy → refused. NOT end-to-end encrypted — never include ID numbers, passwords/PINs, bank/card details or health details; such messages are rejected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoA friend's @handle or exact name (if unique).
bodyYesThe message, max 4000 characters. Write as the person would want to be represented.
conversationIdNoFrom list_conversations. Or use `to`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
statusYes
draftIdNo
messageIdNo
confirmUrlNo
conversationIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

With annotations only covering the safety profile (readOnly=false, destructive=false), the description adds substantial beyond-schema context: it saves a draft with a confirmUrl rather than sending in the person's name, is refused if their policy disables it, is labelled 'via <app name>', is not E2E encrypted, and rejects sensitive content like PINs/bank/health data. This is unusually rich behavioral disclosure.

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 purpose, then the alternative, then safety constraints in a logical order. It is dense and somewhat run-on, but nearly every clause carries safety-critical information that earns its place.

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?

An output schema exists, so return values need not be detailed. For a consent-gated messaging tool the description covers the confirmation flow, policy refusal, encryption limits, and content restrictions — everything an agent needs to invoke it correctly and safely.

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 goes further by specifying the conversationId format (g_<groupId>) and its source (relay_status.groups), which the schema does not fully convey. The only gap is the mild divergence from the schema's stated source (list_conversations vs relay_status.groups).

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') plus the exact channels it targets (friend, anonymous conversation, group chat). It explicitly contrasts itself with the sibling send_to_conversation, so an agent can route without opening either 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 names the preferred alternative ('Prefer send_to_conversation (it resolves names safely)') and gives the conditions that select this tool (group chats via conversationId g_<groupId>). When-to-use, when-to-prefer-alternative, and the consent gate are all stated.

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.