Skip to main content
Glama

Mojeeb

by app.mojeeb.mcp
OverviewDiscussionsAdmin

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). A refused reply isn't stored for its Idempotency-Key, and until 60 seconds after the refused request that key answers 409 idempotency_key_in_progress: once the cause has passed, send it again with a new key. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe 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`.
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. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (destructive/readOnly/openWorld/idempotent hints) by disclosing AI-handoff pausing behavior, the async send lifecycle (queued→sent/delivered/read/failed), idempotency-key refusal semantics including the 60s 409 idempotency_key_in_progress window, and 422 error conditions. This is exactly the mutation/auth/retry context the annotations cannot carry.

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 nearly every sentence earns its place with concrete behavioral detail. It is dense and runs as one long block rather than clearly sectioned, which slightly hurts scanability, but there is little filler.

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 no-output-schema mutation tool, the description is remarkably complete: error codes, retry guidance, async status tracking, AI-handoff interaction, and per-channel constraints are all covered. An agent has everything needed to invoke and follow up correctly.

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 already documents text length/splitting and the agent_id/conversation_id error cases in depth. The description adds no new parameter-level meaning, 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?

States a specific verb+resource ('Sends a text reply to the customer on the conversation's channel') and immediately differentiates from siblings by naming sendWhatsAppTemplate as the alternative when the WhatsApp window is closed. An agent can tell this apart from send_whatsapp_message and assign_conversation without opening any 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?

Gives explicit when-to-use (reply to a customer as your team), when-not (TikTok channel_not_supported; messaging_window_closed on WhatsApp/Facebook/Instagram), and named alternatives (sendWhatsAppTemplate, getConversationMessage for status). It also states what it does NOT do ('never assigns the conversation'), implicitly routing to assign_conversation.

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

All Mojeeb toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources