A
licenseA
qualityA
maintenanceMCP server for AI agents to send notifications, copy to clipboard, request confirmations, and collect text input from users across their devices.
11
527
Apache 2.0
signal-cli-mcp
by jiridudekusy
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@signal-cli-mcpSend a message to Alice saying I'll be late."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
signal-cli-mcp
An MCP server that lets AI assistants (Claude Code) propose sending Signal messages — but nothing is ever sent without explicit human approval. The security guarantee is hard-wired into the architecture: the only path to sending a message goes through signal-client.ts, which is called only after a Decision is approved in approval-core.ts. No tool can bypass this mechanism — if the user rejects or the timeout expires, the message is never sent.
Supported client
Claude Code — supported. You must set
"timeout": 900000in the configuration; otherwise Claude Code will cut off the call during long approvals.Claude Desktop — not supported. It has a hard-coded 60 s tool timeout that cannot be reconfigured.
Related MCP server: call-a-human-mcp
Tools
Tool | Description |
| Proposes sending a message to an individual |
| Proposes sending a message to a group |
| Proposes creating a new group |
Recipients, group targets, and group members may be given either as a contact/group
name or as an E.164 number / group.<id>. The server resolves names against signal-cli's
contacts and groups (exact, case-insensitive match); if nothing matches — or several do — the
call fails with the candidates so the assistant can disambiguate. The approval GUI always shows
the resolved Name (number) so you verify the real recipient before approving.
Setup
1. Start signal-cli-rest-api
docker compose up -dThe Docker Compose file is included in the repository and starts signal-cli-rest-api on port 8080.
2. Link a Signal account
Open in your browser:
http://localhost:8080/v1/qrcodelink?device_name=signal-cli-mcpScan the displayed QR code in the Signal app (Settings → Linked Devices). Verify the link:
curl http://localhost:8080/v1/accountsThe output should contain your phone number.
3. Build the project
npm install && npm run build4. Configure Claude Code
Copy .mcp.json.example to .mcp.json in your project folder (Claude Code loads it from there) and edit:
/ABSOLUTE/PATH/signal-cli-mcp/dist/index.js→ the real absolute path on your machineSIGNAL_ACCOUNT→ your phone number in E.164 format (e.g.+1234567890)
Leave the other variables as-is or adjust as needed. timeout: 900000 is required — without it Claude Code will cut off the call if approval takes longer than 60 seconds.
5. Open the approval GUI
Keep a browser tab open at http://localhost:8088. Proposed messages appear there for approval. Without the tab open approval still works, but you won't see a live preview (you'll get the result when you visit the URL).
Usage
In Claude Code, type something like: "Send John a message that I'll arrive at 6 PM."
Claude Code will call proposeSignalMessage. The proposal appears at http://localhost:8088. Click Approve to send, Reject to decline (with an optional reason), or Edit + Approve to modify the text before sending.
For a detailed walkthrough see docs/MANUAL.md.
Push notifications (optional)
So you don't have to watch the GUI tab, the server can send an ntfy push (macOS + iOS apps) whenever a proposal arrives. Set these env variables:
NTFY_TOPIC— the ntfy topic to publish to (subscribe to it in the ntfy app). Enables notifications.NTFY_BASE_URL— ntfy server (defaulthttps://ntfy.sh; point this at a self-hosted server later).GUI_PUBLIC_URL— where you reach the GUI; used for the tap-through and the action buttons (see below).
With NTFY_TOPIC set, every new proposal triggers a push with the recipient and a text preview.
When GUI_PUBLIC_URL is also set, the notification is actionable:
tapping the notification opens the GUI directly (ntfy
Click),Approve / Reject buttons appear in the notification and POST straight to the GUI's
/actionendpoint — one-tap decisions without opening anything; Open GUI is offered for edits.
Delivery is best-effort — a failed or unconfigured push never blocks approval. Notifications go to ntfy only; they never touch signal-cli.
Privacy note: on the public
ntfy.sh, the topic name is a shared secret and the notification content (recipient, text preview) transits ntfy.sh. For a private setup, self-host ntfy and pointNTFY_BASE_URLat it — planned as a follow-up.
Remote deployment (Docker MCP gateway + Tailscale)
When the server runs remotely (e.g. inside a Docker MCP gateway rather than launched locally by Claude Code):
Transport: the MCP gateway exposes the server over HTTP/SSE; the server itself stays stdio — no code change. Point your MCP client at the gateway.
Reaching the GUI: expose the GUI port over your Tailscale network, e.g.
tailscale serve --bg <GUI_PORT>, and setGUI_PUBLIC_URLto the resulting MagicDNS URL (e.g.https://signal-mcp.<tailnet>.ts.net/). Tailscale is the access boundary — only your devices can reach it, so the GUI needs no extra login. Because your phone is on the tailnet too, tapping the notification (or its Approve/Reject buttons) reaches the GUI straight from the iPhone.Egress: the container needs outbound access to the ntfy server and to signal-cli-rest-api.
Releasing (npm)
The package is published to npm automatically by GitHub Actions
(.github/workflows/publish.yml) when a version tag is pushed,
using npm Trusted Publishing (OIDC) — no token secret, and provenance is generated automatically.
One-time setup on npmjs.com (package → Settings → Trusted Publisher): add a GitHub Actions publisher
with organization/user jiridudekusy, repository signal-cli-mcp, and workflow filename
publish.yml. The workflow already requests id-token: write and upgrades npm to ≥ 11.5.1.
To cut a release:
npm version patch # or minor / major — bumps package.json, commits, and tags vX.Y.Z
git push --follow-tagsThe workflow checks out the tag, runs npm ci, builds, runs the tests, verifies the tag matches
package.json, and publishes. Once published, install with npm install -g signal-cli-mcp (the
signal-cli-mcp binary can then be used as the command in .mcp.json).
Available Tools
3 toolsproposeSignalGroupCreationA
Proposes creating a new Signal group. AWAITS human approval in a local GUI — the call may take several minutes. This is not an error; wait patiently. Nothing is sent without approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Group name. | |
| reason | No | Short rationale for the proposal. | |
| members | Yes | Members — each a contact name (exact) or an E.164 phone number. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the key non-obvious traits: the call blocks for human approval in a local GUI, may take several minutes, and nothing is sent without approval. This is valuable transparency beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and the rest of the sentences provide essential behavioral warnings. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and moderate complexity, the description adequately covers the unique context: the approval workflow, the potential long wait, and the safety guarantee. It explains what the agent should expect when invoking the tool.
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?
The schema already covers all parameters with descriptions (name, reason, members including format expectations). The description adds no additional parameter-level detail, so the baseline score of 3 is appropriate given the high schema coverage.
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 states a specific verb and resource: 'Proposes creating a new Signal group.' This clearly distinguishes it from sibling tools like proposeSignalMessage and proposeSignalGroupMessage, which focus on messages rather than group creation.
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?
The description clarifies the context of use by noting that human approval is awaited and that the call may take minutes. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough for the agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proposeSignalGroupMessageA
Proposes sending a Signal message to a group. AWAITS human approval in a local GUI — the call may take several minutes. This is not an error; wait patiently. Nothing is sent without approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Message text. | |
| reason | No | Short rationale for the proposal. | |
| groupId | Yes | Target group: a group name (exact, case-insensitive) or a group id (group.<...>). |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses the approval requirement, the potential multi-minute wait, that the wait is not an error, and that nothing is sent without approval. This is genuinely helpful and goes beyond what structured data could convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both essential and front-loaded with the most important warnings (approval, wait time, not an error). There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description effectively covers the main contextual challenges for this tool: it is a proposal requiring human approval, may take minutes, and should not be mistaken for an error. It does not explain what happens after approval or the response format, but with simple parameters and no output schema, the key risks are addressed.
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?
The input schema already provides descriptions for all 3 parameters (100% coverage), so the tool description does not need to repeat them. It adds no extra parameter-specific context beyond what the schema already contains, warranting the baseline score.
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 states a specific verb 'Proposes sending' with a clear resource 'Signal message to a group'. This distinguishes it from sibling tools proposeSignalMessage (likely for direct messages) and proposeSignalGroupCreation (creating a group).
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?
The description clearly communicates that the call awaits human approval and may take several minutes, setting proper expectations. It does not explicitly mention alternatives or when not to use the tool, but the scope is clear from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proposeSignalMessageA
Proposes sending a Signal message to an individual. AWAITS human approval in a local GUI — the call may take several minutes. This is not an error; wait patiently. Nothing is sent without approval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Message text. | |
| reason | No | Short rationale for the proposal, shown to the user. | |
| recipient | Yes | Recipient: a contact name (exact, case-insensitive) or an E.164 phone number (e.g. +1...). The server resolves a name to a number; if no contact or several match, the call fails so you can disambiguate. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explicitly warns that the call awaits human approval in a local GUI, may take several minutes, is not an error, and that nothing is sent without approval. This fully covers the tool's non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the key purpose and the critical behavioral warning. Every sentence adds necessary information, and there is no wasted text.
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 or annotations, the description covers the essential context: purpose, recipient scope, approval workflow, duration warning, and the guarantee that nothing is sent without approval. Parameter details are fully handled by the schema, so no significant gaps remain.
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?
The input schema provides 100% coverage with meaningful descriptions for all three parameters, including recipient resolution and failure conditions. The description itself adds no parameter-level details, but since the schema is thorough, a baseline of 3 is appropriate.
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 clearly states a specific action ('Proposes sending a Signal message to an individual') and differentiates it from sibling tools that target groups or group creation. The verb 'propose' and resource 'individual message' are unambiguous.
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?
The description gives clear context by specifying 'to an individual,' which implies this tool is for person-to-person messages rather than group messages. It does not explicitly name alternatives or when-not-to-use, but the sibling tool names and the individual/group contrast provide enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.1/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: sending to an individual, sending to a group, and creating a group. The recipient type and action are explicit in the names, leaving no ambiguity.
Naming Consistency5/5
All tools follow a consistent 'propose[Action]' pattern with clear noun phrases (SignalMessage, SignalGroupMessage, SignalGroupCreation). The naming is uniform and predictable.
Tool Count3/5
At 3 tools, the count is at the low end of the typical range. While each tool earns its place, the server feels minimal and could benefit from a few more operations to feel well-rounded.
Completeness2/5
The server covers sending messages and creating groups but lacks any receive, list, or management capabilities. For a Signal client, this is a significant gap that would prevent agents from performing common workflows.
Maintenance
ActivityStale
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI agents to pause and request human approval or information via Slack, Telegram, or macOS dialogs before proceeding with actions.15Apache 2.0
- AlicenseAqualityAmaintenanceAn MCP server that gives AI agents permission-gated, audit-logged access to private email providers (Proton Mail via Bridge and plain IMAP), running locally with OAuth-based authentication and human-controlled escalation for destructive operations.6628810MIT
- AlicenseAqualityDmaintenanceAn MCP server that acts as an AI assumption firewall, intercepting risky decisions, detecting contradictions, and routing human approval requests via Telegram or Slack.8MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jiridudekusy/signal-cli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server