Skip to main content
Glama

ethora-mcp-server

by io.github.dappros
OverviewDiscussionsAdmin

Send Chat Message

ethora-message-send

Post a message into a chat room of an app (POST /v2/apps/:appId/chats/broadcast targeting one room). The message is attributed to the app's broadcast sender (override the shown name with senderName). Use it to seed or test a conversation, e.g. right after ethora-agent-invite, and set waitForReplySec (up to 60) to wait for an AI agent's answer; replies are returned in replies. Identify the room by roomJid (${appId}_${chatId}, exactly what ethora-chat-create returns as jid) or by the bare chatId plus the selected app. Requires: a room in the selected app (ethora-chat-create); for replies, an agent invited into it (ethora-agent-invite). Auth: user auth (the default on the hosted server) or B2B; app-token mode is not accepted by this route. Errors: 401 not logged in; 403 not the app owner; 404 unknown app/room; 422 empty text. Reply detection needs the message archive (MAM) on the deployment; when it is unavailable replies is null and historyUnavailable is true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesMessage body to post (1-4000 chars).
appIdNo24-char hex appId. Optional when `roomJid` carries it or an app is selected.
chatIdNoChat id: either the Mongo chat `_id` (as listed by the app's chat list) or the suffix after `${appId}_` in the room JID. Needs an app: pass `appId` or select one with `ethora-app-select`.
roomJidNoRoom JID `${appId}_${chatId}` (optionally with `@conference.<host>`), as returned by `ethora-chat-create`. Either this or `chatId` is required.
senderNameNoDisplay name shown as the message sender (defaults to the app's broadcast sender / app name).
waitForReplySecNoSeconds to wait for a reply from someone else in the room (an AI agent, typically). 0 (default) returns right after posting.

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?

Beyond the annotations (readOnlyHint=false, etc.), the description discloses specific behavioral traits: auth modes accepted/rejected, error codes (401, 403, 404, 422), the MAM dependency where `replies` becomes null and `historyUnavailable` becomes true, and the wait/reply semantics. This significantly exceeds what annotations alone convey.

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?

The description is longer than average but well-structured into purpose, usage, prerequisites, auth, errors, and reply-detection. Each sentence carries distinct information and there is no fluff or repetition. It is front-loaded with the core action and use case.

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?

Despite having no output schema, the description covers return behavior (`replies`, `historyUnavailable`), errors, auth requirements, prerequisites, and room identification. For a 6-parameter tool with this complexity, nothing essential is missing for an agent to invoke it correctly.

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 baseline is 3. The description adds meaning beyond schema by explaining room identification via `roomJid` vs `chatId` and the relationship to `ethora-chat-create`'s return value, the `senderName` override, and `waitForReplySec`'s effect on `replies`. This enriches rather than repeats schema details.

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 description explicitly states 'Post a message into a chat room of an app' with a specific HTTP route and 'targeting one room', making the action and resource clear. It distinguishes this from siblings like ethora-chat-create and ethora-chat-history by focusing on message posting, not room creation or reading history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance ('Use it to seed or test a conversation, e.g. right after ethora-agent-invite') and lists prerequisites (`ethora-chat-create`, `ethora-agent-invite`). It does not state a 'when not to use' or name an alternative sending tool, but the context is clear and actionable.

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

All ethora-mcp-server 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