ntfy-mcp

ntfy-mcpNotifications your MCP client can send, read back and correct

An MCP server for ntfy: publish notifications, read back what was sent, revise one in place while a job runs, and administer accounts and topic access.

Get started
Tools reference
GitHub

  • A progress report stays one notification

    The id publish_message returns is also the sequence id of the notification, and update_message replaces its content in place. Subscribers watch one notification change from "building" to "deployed" instead of collecting five.

  • NTFY_TOPICS is the fence

    On ntfy a topic name is a bearer credential — knowing it is often the whole of the access control. One variable names the topics this server may touch and supplies the default when a tool omits one, so the name stays out of the tool arguments and every read and write is bounded by the same list.

  • Only the tools you want

    NTFY_READ_ONLY=true registers the read tools and nothing else. NTFY_ALLOW_TOOLS cuts finer — essential for a curated six, your own comma-separated list, or a whole family with list_* — and NTFY_DENY_TOOLS subtracts. Whatever is filtered out does not exist on the protocol rather than failing when called, and a name that matches no tool stops the server at startup instead of quietly going missing.

  • Careful with what it hands back

    Deleting anything, and creating or re-scoping an account, asks a person first through MCP elicitation — a dialog the model cannot answer on its behalf, falling back to a token bound to the exact target where the client cannot show one. Notification content is marked as untrusted data, access tokens are stripped out of get_account, and a click or action URL must be http or https because the recipient device is what opens it.

ntfy-mcp architectureAn MCP client talks to ntfy-mcp over stdio; ntfy-mcp publishes notifications and polls the message cache over HTTPS against an ntfy server, which pushes them to the subscribed devices. Because a published message keeps its sequence id, the same notification can be revised in place instead of sending another one.MCP clientClaude, Codex, …ntfy-mcp13 toolstopic allow-listasks a personntfypub-sub serverstdioHTTPS · publishHTTPS · pollsubscribed devices get the pushupdate_message revises it in place
One stdio server between the MCP client and ntfy — publishes over HTTPS and polls the message cache over the same API, bounded by the topic allow-list, with destructive calls put to a person first.

See it in action ​

Demo of ntfy-mcp over the MCP inspector

Running it elsewhere ​

A client that cannot spawn a local process — ChatGPT connectors, Claude on the web, Cursor, LibreChat — cannot start ntfy-mcp the way Claude Code does. mcp-hub is the bridge: one container serves many stdio MCP servers over Streamable HTTP, with an OAuth 2.1 login behind a single password and long-lived tokens for the clients that cannot do OAuth. Its /hub endpoint puts every server behind six meta-tools, so one connector reaches all of them without N×tool schemas in the model's context, and it speaks both protocol revisions — a question this server asks travels through it to the person at the far end instead of ending at the gateway.

Its configuration is Claude Code's mcpServers format, so the entry you already have is the entry it takes: Through mcp-hub.

Released under the MIT License.

Copyright © 2026 Willi Thiel