Signal MCP vs Ethora MCP Server — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
Signal MCP vs Ethora MCP Server
In-depth architectural comparison of the Signal MCP and Ethora MCP Server MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
Signal MCP
Communication · Local stdio
Quality: 57/100 (Good) | Auth: other
Ethora MCP Server
Communication · Local stdio
Quality: 64/100 (Good) | Auth: OAuth 2.0
Verdict Summary: Choose Signal MCP if you need specialized Communication tools running via a local process. Choose Ethora MCP Server if your workspace requires Communication integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose Signal MCP when:
You need dedicated capabilities in the Communication domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: other (Free / Open Source).
Full Signal messenger MCP server and CLI. Send/receive messages, manage groups and contacts, search history, handle attachments and reactions. Runs locally via signal-cli — no third-party servers.
MCP server for the Ethora chat & messaging platform: chat ops, AI agents, RAG, automation.
Send a text message to a Signal contact. The message is delivered end-to-end encrypted. Returns the sent timestamp, which can be used as target_timestamp for react_to_message or edit_message. To reply/quote a specific message, provide quote_author and quote_timestamp (get timestamps from get_conversation). Use send_group_message for group chats, send_attachment for files/images.
send_group_message
Send a text message to a Signal group. The message is delivered end-to-end encrypted to all group members. Returns the sent timestamp, which can be used as target_timestamp for react_to_message or edit_message. To @mention a member, include their name in the message text and pass a mentions list where each entry has start (character index of the mention in the text), length (character count), and author (E.164 phone number). To reply/quote a message, provide quote_author (sender's phone number) and quote_timestamp (from get_conversation). Use list_groups to get group_id values. Use send_group_attachment to send files or images to a group. Do NOT use for direct messages to a contact — use send_message instead.
send_note_to_self
Send a note to yourself via Signal's 'Note to Self' / saved messages feature. The note is synced across all your linked Signal devices. Useful for saving reminders, bookmarks, or drafts that sync to your phone. message supports lightweight markdown for Signal's native rich text: **bold**, ~~strikethrough~~, `monospace` — use it to visually distinguish different kinds of notes (e.g. a bold title per note) instead of plain text blobs. Pass attachments (e.g. a QR code image) and quote_author/quote_timestamp (to thread a follow-up under a previous note, from a prior send_note_to_self result) to combine content in one message instead of separate calls.
Ready-to-Paste Client Configurations
Paste either (or both) of these JSON server blocks into your client config file (e.g. claude_desktop_config.json or ~/.cursor/mcp.json).
Signal MCP is categorized under Communication and uses a local stdio subprocess. In contrast, Ethora MCP Server belongs to Communication using local stdio subprocess. Select Signal MCP when you need capabilities focused on communication and Ethora MCP Server when you require tools for communication.
Edit the text of a previously sent message. Sends the edit via signal-cli to all original recipients; they see the updated text inline with an '(edited)' label. Only the message text can be modified — attachments, quoted replies, and reactions are immutable. The edit must reference the exact timestamp of the original message as returned by send_message or get_conversation. Edits can only be made to messages you sent; editing someone else's message returns an error. There is no enforced time limit, but Signal clients may ignore edits on very old messages. Provide recipient for a DM edit or group_id for a group edit; exactly one is required. Use when correcting a typo or updating information in a message you already sent. Do NOT use to change who a message was sent to — send a new message instead.
receive_messages
Manually poll signal-cli for new messages and store them. Prefer get_unread — it does this automatically and returns results in one call. Use receive_messages only if you want to poll without reading results.
receive_direct
Receive messages by calling signal-cli directly, bypassing the daemon. Use this as a fallback when the daemon is stuck or unresponsive — it stops the daemon, calls signal-cli receive directly, then lets the daemon restart. Prefer receive_messages (daemon mode) for normal use; use this only for troubleshooting.
list_contacts
List all Signal contacts known to this account, including names and phone numbers. Use the optional search parameter to filter by name or number substring. Returns contacts from signal-cli's local contact store. Use get_profile to fetch the current Signal profile for a specific contact.
list_groups
List all Signal groups this account belongs to, including group name, ID, members, and admin list. The group_id returned here is required for send_group_message, send_group_attachment, and update_group. Use update_group to modify a group, or leave_group to exit.
get_conversation
Get recent message history with a contact or group from local store. Automatically marks returned messages as read in the local store (does NOT send a Signal read receipt — call send_read_receipt for that).
search_messages
Full-text search across all locally stored messages by keyword or phrase. Searches message bodies using SQLite FTS — results are ranked by relevance. Only messages in the local store are searchable; messages never received on this device are excluded. Use sender to narrow results to a specific conversation. Use limit and offset to paginate through large result sets. Use when looking for a specific message or topic across all Signal conversations. Do NOT use to browse a conversation chronologically — use get_conversation for that.
send_attachment
Send one or more files or images to a Signal contact. Supports photos, videos, documents, and audio files. Use path for a single file or paths to send multiple files in one message. Set view_once=true to send media that auto-deletes after the recipient views it once. For groups use send_group_attachment instead.
send_group_attachment
Send one or more files (photos, videos, documents, audio) to a Signal group in a single message. All current group members receive the attachment via the normal Signal encrypted delivery pipeline. Provide path for a single file or paths for multiple files sent together in one message. Set view_once=true so each member can only open the media once before it disappears — ideal for sensitive images; does not apply to document types. The file must exist and be readable on the local filesystem; non-existent paths return an error. Use list_groups to obtain the group_id. Use when sharing a file with a group chat. Do NOT use for direct messages — use send_attachment instead. Do NOT use when you only want to send text — use send_group_message instead.
+68 more tools listed on main page
Ethora MCP Server Tools (89)
ethora-configure
Set the Ethora API URL and credentials for this MCP session. Stores values in memory only; each call merges with omitted fields kept. Alternative to env vars (ETHORA_API_URL / ETHORA_APP_JWT / ETHORA_APP_TOKEN / ETHORA_B2B_TOKEN). On a hosted server `apiUrl` is fixed and cannot be changed; credentials are per session.
Auth: none required — this establishes auth material. Errors: only if a value is structurally invalid. Follow with an `ethora-auth-use-*` tool to pick the active mode.
ethora-status
Report the current Ethora MCP session state: configured API URL, active auth mode, which credentials are present (booleans like `hasAppJwt` — values never echoed), the selected appId/agentId, and `hosted`/`sessionId` on the hosted (Streamable HTTP) server.
Auth: none required. Errors: effectively none. Related: `ethora-doctor` for an active connectivity check.
ethora-help
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-run-recipe`.
ethora-run-recipe
Execute a built-in recipe — an ordered sequence of this server's own tool calls — by id. Recipes capture common flows (B2B bootstrap, broadcast, sources ingest). Use `dryRun: true` to preview resolved steps. Omit `recipeId` to list runnable recipes for a `goal`.
Requires: the inputs the chosen recipe lists; call without `recipeId` first to see the recipes and their required inputs.
Auth: depends on the recipe's steps — configure those first (see `ethora-help`). Errors: stops at the first failing step and returns the partial log; a missing required `vars` entry fails fast before any step runs.
ethora-doctor
Diagnose the session: validate the config is internally consistent for the active auth mode and ping the Ethora API (`GET /v1/ping`). Returns `{ state, checks, ping, suggestions }`.
Auth: none required; report is tailored to whatever credentials are set. Errors: rarely throws — instead returns `suggestions` and a `ping.ok: false` block when the API is unreachable.
ethora-auth-use-app
Switch this session's active auth mode to app-token, so subsequent app-scoped calls authenticate with the configured `appToken`.
Auth: requires an `appToken` to already be configured (via `ethora-configure`, ETHORA_APP_TOKEN env, or `ethora-app-select`). Errors: returns an error if no `appToken` is configured. Related: use after `ethora-app-select`.
ethora-auth-use-user
Switch this session's active auth mode to user-session, so subsequent calls authenticate as a logged-in Ethora user.
Auth: the switch needs nothing, but user-auth tools only work once `ethora-user-login` stores a user token (login also needs a configured `appJwt`). Errors: none on the switch; downstream tools return 401 until login succeeds. Related: follow with `ethora-user-login`.
ethora-auth-use-b2b
Switch this session's active auth mode to B2B, so subsequent calls authenticate as a tenant actor via the `x-custom-token` header.
Auth: requires a `b2bToken` (JWT with `type=server`) to already be configured (via `ethora-configure` or ETHORA_B2B_TOKEN env). Errors: returns an error if no `b2bToken` is configured. Related: server-side automation — pairs with `ethora-b2b-app-create`, `ethora-users-batch-create-v2`, `ethora-app-tokens-*-v2`.
ethora-app-select
Set the current app context for this session so app-scoped tools can omit their `appId` argument. Stores `currentAppId` and, if given, `appToken` (which defaults the auth mode to app-token unless `authMode` overrides).
Auth: none required to set the context. Errors: effectively none — a non-existent `appId` is not validated here; the first app-scoped API call surfaces the 404. Related: pairs with `ethora-auth-use-app`.
ethora-chats-broadcast-v2
Enqueue an asynchronous broadcast job posting a message to one or more chat rooms of an app — returns a `jobId`; messages are not sent synchronously. Targeting is exclusive: `allRooms`, `chatIds`, or `chatNames`, not a mix.
Requires: a selected app with at least one room (`ethora-app-create-chat`).
Auth: app-token mode OR B2B mode with an explicit `appId`. Errors: 401/403 wrong auth; 400 no target or conflicting targets; 404 unknown `appId` or room. Related: track with `ethora-wait-broadcast-job-v2`.
ethora-chats-broadcast-job-v2
Fetch the current status and per-room results of a broadcast job by `jobId` (one-shot, no polling). Returns the job object with its `state` (pending/running/completed/failed).
Requires: a selected app with at least one room (`ethora-app-create-chat`).
Auth: app-token mode OR B2B mode with an explicit `appId` — must match the auth used to enqueue the job. Errors: 401/403 wrong auth; 404 unknown `jobId`. Related: `ethora-wait-broadcast-job-v2` for a blocking wait.
ethora-wait-broadcast-job-v2
Block until a broadcast job reaches a terminal state (`completed` or `failed`) or until `timeoutMs` — read-only polling wrapper around `ethora-chats-broadcast-job-v2`. Returns `{ done, state, job }`, or `{ done: false, reason: "timeout" }` on timeout.
Requires: a `jobId` returned by `ethora-chats-broadcast-job-v2`.
Auth: app-token mode OR B2B mode with an explicit `appId` — must match the auth used to enqueue the job. Errors: 401/403 wrong auth; 404 unknown `jobId`.