Ethora MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ethora-statusA | Report the current Ethora MCP session state: configured API URL, active auth mode, which credentials are present (booleans like |
| ethora-helpA | Task-oriented orientation for this MCP server: explains the three Ethora auth modes (user / app-token / B2B) and recommends next tool calls + recipes based on current session state.
Auth: none required — inspects state, no API calls. Errors: effectively none. Related: pass a recommended recipe id to |
| ethora-app-selectA | Session-only: remembers which app later calls refer to. Changes nothing on the server and can be called again at any time to switch. Set the current app context for this session so app-scoped tools can omit their |
| ethora-source-site-crawl-waitA | Adds the crawled pages to an agent's knowledge base (the one named by |
| ethora-source-doc-uploadA | Upload documents (1–5; PDF, text, etc.) into an agent's knowledge base (the one named by |
| ethora-user-loginA | Authenticate as an existing Ethora user with email + password. Stores the user session token in this MCP session and unlocks user-auth tools ( |
| ethora-user-registerA | Create a new Ethora user account by email + first/last name, then log in and bind the session. A password is generated when omitted and returned once. By default also mints a long-lived API key so an agent can reconnect later with |
| ethora-api-key-createA | Mint a long-lived, revocable API key for the currently logged-in user. The key is a user token: send it as |
| ethora-feedback-submitA | Send feedback about Ethora to the Ethora team: something that does not work, behaves differently from what the tool description promised, is missing, or is badly documented. It reaches the team directly, so prefer it over guessing or silently giving up when a tool fails. Recent failures in this session (tool, error code, request id) are attached automatically when |
| ethora-widget-snippet-getA | Generate the tag that embeds the Ethora AI chat widget (the floating launcher + chat panel that website visitors use) for an app, plus the prerequisites that must hold before it answers. No API call; pure generator using this deployment's hosted widget URL and public API base. The widget answers with the app's ACTIVE bot: for API-created apps run |
| ethora-app-listA | List all Ethora apps (tenants) owned by the currently logged-in user. Returns an array with |
| ethora-app-createA | Create a new Ethora app (tenant) owned by the currently logged-in user. Allocates a fresh 24-char hex |
| ethora-app-updateA | Overwrites the fields you pass; previous values are not kept and cannot be restored from the API, so confirm changes to the prompt, name or settings with the user first. Update mutable fields on an app the caller owns (displayName, domainName, appTagline, primaryColor, botStatus). Partial update - omitted fields are left unchanged.
Requires: an |
| ethora-chat-createA | Create a new chat room (MUC room) inside an app the caller owns. Every room created this way is listed in the app's rooms ( |
| ethora-agent-listA | List AI agents ( |
| ethora-agent-createA | Create a reusable AI agent (POST /v2/apps/:appId/agents). Works in user auth mode (the normal hosted mode) or B2B mode; app-token mode is not accepted by the backend. Each agent is a persona - name, avatar, system prompt, LLM config, plus response-gate settings (responseMode, cooldownSec) that control when it speaks in a room. For multi-agent scenarios (two or more personas conversing in one chat) create each one separately, then |
| ethora-agent-updateA | Overwrites the fields you pass; previous values are not kept and cannot be restored from the API, so confirm changes to the prompt, name or settings with the user first. Update a saved AI agent (PUT /v2/agents/:agentId). All fields are optional - only what you pass is updated. Common uses: tune the system |
| ethora-agent-activateA | Make an agent the app's ACTIVE widget bot: sets |
| ethora-agent-inviteA | Invite an Agent into a chat room. Multiple agents can coexist in the same room — call this tool once per agent and they will all appear as members able to converse. Lazily creates a per-App BotInstance (an Ethora user with isBot:true) if one does not already exist for (agent, app). Spawns the XMPP client live; no ai-service restart required. For the full multi-agent recipe see the |
| ethora-message-sendA | 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 |
| ethora-chat-historyA | Read the archived messages of a chat room (GET /v2/apps/:appId/chats/:chatId/messages, newest last). Returns |
| ethora-tools-enableA | Session-only: changes which tools this connection lists. Touches no account data. Only the core tools are listed by default. Call this to enable another group for this session; the tool list refreshes automatically (tools/list_changed). On the hosted server the enabled groups are remembered for the signed-in account, so a client that opens a new session per call keeps them. Without |
| searchA | Search the Ethora documentation and tool reference: auth model (app JWT vs app token vs B2B token vs API keys), hosted-server getting started, chat-component and backend SDK quickstarts, recipes, and a reference entry for every tool with its inputs. Use it for any "how do I ..." question about Ethora before guessing; then call |
| fetchA | Fetch the full text of a documentation section or tool reference entry by the id returned from |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| ethora-vite-quickstart | Explains how to add chat component to a Vite app, and how to avoid demo tokens in production. |
| ethora-nextjs-quickstart | Explains how to add chat component to a Next.js app and handle auth safely. |
| ethora-backend-sdk-quickstart | Shows how to integrate Ethora backend SDK in a Node.js backend. |
| ethora-auth-map | Explains appJwt vs appToken vs b2bToken and when to use each. |
| ethora-recipes | Common MCP tool sequences for local user-auth and server-side B2B/app-token flows. |
| ethora-agents-quickstart | End-to-end recipe for creating Agents, indexing their RAG, marking them public, inviting them into rooms, and running the two-agents-in-one-room demo. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| ethora-auth-map | appJwt vs appToken vs b2bToken |
| ethora-chat-component-quickstart | Vite/Next quickstart + replacing demo tokens |
| ethora-backend-sdk-quickstart | @ethora/sdk-backend quickstart |
| ethora-recipes | Common MCP recipes |
TDQS
Scored across 24 tools
Operational tools have clear resource/action boundaries, and potentially confusing agent steps such as create, invite, and activate are explicitly differentiated. There is minor overlap among the orientation and discovery tools (`ethora-status`, `ethora-help`, `search`, and `fetch`), while registration also overlaps slightly with login and API-key creation, but the descriptions generally resolve these choices.
Names consistently use kebab-case and usually follow an `ethora-<resource>-<action>` pattern, with predictable app, agent, user, and source families. Bare `search` and `fetch`, noun-only names such as `ethora-status` and `ethora-help`, and the action-less `ethora-chat-history` prevent the pattern from being fully uniform.
At 24 tools, the exposed set is at the heavy end and spans authentication, documentation, apps, agents, chat, knowledge sources, and widgets. Most tools earn their place and session-based group enabling helps manage expansion, but the listed surface is still large for one server.
The tools cover a core registration/login-to-app-to-agent-to-room-to-widget workflow, but lifecycle coverage is uneven: room discovery/deletion, app and agent deletion, API-key revocation, and source listing/deletion are absent. Many descriptions reference companion tools outside the supplied set; `ethora-tools-enable` suggests gated groups may fill some gaps, but the visible surface alone still has dead ends.