mcp-signal
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SIGNAL_DB_KEY | No | Raw key for encrypted desktop DBs if needed. | |
| SIGNAL_ACCOUNT | No | Your Signal account phone number (e.g., +441234567890), required for sending messages. | |
| SIGNAL_CLI_PATH | No | Override the `signal-cli` binary path. | |
| SIGNAL_DATA_DIR | No | Override the Signal Desktop data directory. | |
| SIGNAL_DB_PASSWORD | No | Password for encrypted desktop DBs if needed. |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_statusA | Check whether the Signal MCP server can read local messages and send outbound messages. Returns boolean fields: source_dir_exists, signal_cli_available, signal_account_configured, read_available, send_available. Read-only with no side effects. Call this before read or send operations to verify configuration; call pairing_status instead to check first-run device-linking state. |
| pairing_statusA | Report the Signal device-linking setup state for first-run pairing, so a client can surface the live link QR. Returns a setup_state envelope: state 'ready' with the linked account once signal-cli is linked; 'awaiting_qr' with a 'qr_payload' sgnl://linkdevice URI to scan in Signal (Settings → Linked devices → Link new device) while a link is in progress (no payload yet on the first call, until the URI is captured); or 'error' when signal-cli is unavailable. Read-only from the caller's view, but the first call on an unlinked device starts a background signal-cli link process as a side effect. Poll this to drive a pairing UI; call get_status instead to check read/send availability once linked. |
| list_chatsA | List direct and group Signal chats from the local desktop database, sorted by most recent message. Each result includes name, phone number, message count, and a preview of the last message. Read-only with no side effects. Use this to discover exact chat names before calling read_messages or search_messages. Use list_groups instead when you need group_id values for send_message. |
| read_messagesA | Read messages from a single Signal chat, returned newest-first. Each message includes sender, date, body text, reactions, and attachment metadata. Read-only with no side effects. Requires an exact chat name from list_chats. Use search_messages instead to find messages by keyword across chats. |
| search_messagesA | Search Signal message bodies for a keyword, within one chat or across all chats, returned newest-first. Each result includes sender, date, chat name, body text, reactions, and attachment metadata. Read-only with no side effects. Use this to find messages by content. Use read_messages instead to browse a specific chat chronologically. |
| list_groupsA | List Signal groups with group_id, name, description, members, and admin lists, sorted alphabetically. Read-only with no side effects. Queries signal-cli when available; falls back to the local desktop database (without group_id). Use this to obtain group_id values needed by send_message. Use list_chats instead for a combined view of both direct and group chats. |
| chat_activityA | List Signal chats ranked by recent activity, showing last message date, last reply date, and count of unanswered inbound messages. Read-only with no side effects. Use this to identify chats that need a response. Use list_chats instead for a general chat directory with message previews. |
| decrypt_attachmentA | Decrypt a locally stored Signal attachment and return the path to the decrypted file. The encrypted_path and local_key values come from attachment metadata in read_messages or search_messages results. Read-only on Signal data; writes a decrypted copy to a temporary directory (the temp file is not auto-cleaned). Returns the absolute path to the decrypted file as a string on success, or a string starting with 'Error:' on failure (missing file, wrong key length, or HMAC mismatch). Use this after reading messages that contain attachments. |
| send_messageA | Send a text message via Signal to a direct recipient or group. This is a write operation that delivers a real message through signal-cli. Sends are not reversible from this server — Signal supports user-initiated message deletion only via the official clients. Exactly one of phone_number, group_id, or chat_name must be supplied; providing zero or more than one raises an error. Rate-limited to 1 message per recipient per second and 10 messages per 60-second window globally. Requires signal-cli and SIGNAL_ACCOUNT to be configured — call get_status first to verify send_available is true. Returns target_type, target identifier, and timestamp on success. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| summarise_chat | Summarise recent messages in one Signal chat. |
| discover_topics | Find the recurring topics across Signal chats, or within one chat. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Most tools target clearly distinct operations, especially read/search/send/decrypt. The main overlap is among list_chats, list_groups, and chat_activity, but descriptions explicitly differentiate their purposes (combined directory, group_id lookup, activity ranking).
The tool set uses consistent snake_case and mostly follows a verb_noun or noun_status pattern. pairing_status and chat_activity deviate slightly from the dominant verb_noun convention, but remain readable and predictable.
Nine tools is well-scoped for a Signal integration covering setup, discovery, reading, searching, attachment decryption, and sending. Each tool appears to earn its place without obvious redundancy.
The surface covers the core Signal lifecycle: status, pairing, chat/group discovery, message reading/searching, attachment decryption, and sending. Minor gaps exist around sending attachments, reactions, or deletion, but core workflows are covered.