Skip to main content
Glama

Reply in a conversation

send_conversation_message
Destructive

Reply in a conversation

Sends a text reply to the customer on the conversation's channel, as your team. It shows in the dashboard as written by the person who created the key. When the agent's ai_handoff_enabled is on, it pauses the AI for the agent's handoff window like any teammate's reply (when it is off, the AI keeps answering); when the pause ends, the AI may write once more if follow-ups are on for the channel (resumeConversationAi or ai_enabled: false prevents it). It never assigns the conversation. Refused before anything is saved (422): channel_not_supported on a channel Mojeeb can't send on (TikTok), and messaging_window_closed on WhatsApp, Facebook or Instagram when the customer hasn't written in the last 24 hours (on WhatsApp, send a template with sendWhatsAppTemplate instead). The reply is sent after the response: it starts queued and its status moves on to sent, delivered, read or failed; follow it with getConversationMessage. On a website conversation it is stored as sent and appears in the open chat.

The MCP server sends this call with an idempotency key of its own, so a retry after a timeout never sends it twice.

Input Schema

NameRequiredDescriptionDefault
textNoThe reply; text that is only spaces is refused. WhatsApp takes up to 4,096 characters as one message. Messenger and Instagram receive a long reply in up to 5 parts (of up to 1,900 and 900 characters), split at paragraph, line or sentence breaks. On Instagram, text that doesn't fit in 5 parts is cut and the message still reads `delivered`, so keep Instagram replies within 2,700 characters to be sure they arrive whole.
agent_idYesThe agent the resource belongs to. Another company's agent, or the nil UUID, is `404 agent_not_found`; an agent outside the key's agent list is `403 agent_not_authorized`.
media_urlNoOne file to send: an https link Mojeeb downloads (a public address, no redirects) or the `url` of a Mojeeb upload of this agent (`createUpload`). A JPEG, PNG or WebP image up to 10 MB, an MP4 or MOV video up to 16 MB (re-encoded for WhatsApp; videos sent with messages have a budget of their own, 10 a minute per key, past which they are `429 video_send_rate_limited`), or a PDF or DOCX document up to 20 MB. Stored and shown in the conversation as a file the composer sent would be.
conversation_idYesOne of the agent's conversations. Another agent's conversation, or a deleted one, is `404 not_found`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / media_url
      Added value: +{
      +  "description": "One file to send: an https link Mojeeb downloads (a public address, no redirects) or the `url` of a Mojeeb upload of this agent (`createUpload`). A JPEG, PNG or WebP image up to 10 MB, an MP4 or MOV video up to 16 MB (re-encoded for WhatsApp; videos sent with messages have a budget of their own, 10 a minute per key, past which they are `429 video_send_rate_limited`), or a PDF or DOCX document up to 20 MB. Stored and shown in the conversation as a file the composer sent would be.",
      +  "maxLength": 4096,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "agent_id",
      -  "conversation_id",
      -  "text"
      -]New value: +[
      +  "agent_id",
      +  "conversation_id"
      +]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only give the coarse safety profile (readOnly=false, destructive=true, openWorld=true, idempotent=false); the description goes well beyond that with AI-handoff pausing semantics, the queued→sent/delivered/read/failed lifecycle, pre-save 422 refusals, and a note that the MCP layer supplies an idempotency key so timeout retries do not double-send. That idempotency note sits in mild tension with `idempotentHint: false` but clarifies rather than contradicts it, since it describes transport-level retry safety, not tool-level repeat semantics.

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 purpose, then handoff behavior, then refusals, then async status — a sensible order with dense, non-redundant sentences. It is on the long side and the headline 'Reply in a conversation' restates the title, and the status/error detail could be tightened, but nearly every sentence carries information needed to call it correctly.

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?

With no output schema, the description supplies exactly what is missing: the asynchronous result model, where to observe it (`getConversationMessage`), the channel-specific failure preconditions, and website-channel behavior. Nothing an agent needs to invoke this correctly or interpret a 422 is absent.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema itself already carries the rich per-parameter detail (character limits per channel, media type/size matrix, 404/403 agent errors). The description body adds little parameter-level meaning beyond channel-specific routing guidance, so the baseline 3 applies.

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 opening sentence names a specific verb and resource plus scope: 'Sends a text reply to the customer on the conversation's channel, as your team.' It distinguishes the channel-agnostic reply path from the WhatsApp-specific one by pointing at `sendWhatsAppTemplate` for the template case, so an agent can place it among the messaging siblings without opening a 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?

It states when the tool applies, when it is refused (channel_not_supported on TikTok, messaging_window_closed on WhatsApp/Facebook/Instagram after 24h), and names the alternative to use in that case (`sendWhatsAppTemplate`). It also tells the agent to follow delivery with `getConversationMessage`, and explicitly notes the tool never assigns the conversation, excluding `assign_conversation`.

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