ntfy-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NTFY_URL | Yes | Base URL, e.g. https://ntfy.example.net. Required. | |
| NTFY_TOKEN | No | Access token (tk_...). Mutually exclusive with NTFY_USERNAME and NTFY_PASSWORD. | |
| NTFY_TOPICS | No | Comma-separated topics this server may use. The first is the default when a tool omits one, and the list restricts every tool, read and write — access grants included. | |
| NTFY_PASSWORD | No | Basic-auth password. | |
| NTFY_USERNAME | No | Basic-auth user. Must be set together with NTFY_PASSWORD. | |
| NTFY_READ_ONLY | No | true, 1 or yes (any case) registers only the six read tools. Default false. | false |
| NTFY_DENY_TOOLS | No | Same syntax as NTFY_ALLOW_TOOLS; removed from whatever NTFY_ALLOW_TOOLS left. | |
| NTFY_ALLOW_TOOLS | No | Comma-separated tool names, list_* prefixes, or essential for a curated preset. | |
| NTFY_INSECURE_TLS | No | true accepts self-signed certificates (scoped to this connection). | false |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_messagesA | Polls the cached messages of one or more topics, oldest first. Returns "next_since": pass it back as "since" to get only what arrived after this call. ntfy has no way to list the topics that exist — a topic is created by publishing to it. You either know the name or you find it in get_account or list_users. Retention is whatever the instance configures (12 hours by default), so an empty result usually means "nothing recent", not "no such topic". Message bodies are shortened here; use get_message for one in full. Entries with an "updates" field revise an earlier notification rather than being new ones. |
| get_messageA | Fetches a single cached message in full, including the untruncated body, its action buttons and any attachment. Ids come from list_messages or from the result of publish_message. |
| check_topic_accessA | Reports whether the configured credentials may SUBSCRIBE to each topic, without publishing anything. Read the result carefully: ntfy grants read and write separately, and this endpoint tests the read side only. A write-only publishing token is denied here and can still publish perfectly well — that combination is the single most common source of confusion with ntfy. |
| get_server_infoA | Health, capabilities and usage of the ntfy instance. Health, config and stats are public, so this is the one tool that works before the credentials are right — a good first call after setup. Each section is fetched independently; one that is unavailable is reported as such and does not fail the call. "version" needs an admin account, so its absence is normal. |
| get_accountA | Identity, role, tier, limits and current usage of the configured credentials. Access token values are redacted — only their labels and timestamps are shown. |
| list_usersA | Every account on the instance with its per-topic grants — the answer to "who can read or write topic X". Requires an admin account; get_server_info reports whether the current one qualifies. Where NTFY_TOPICS restricts this server, the grants are reported against those topics only: a grant on a wildcard appears once per allowed topic it covers, and one that covers none of them is not shown at all. |
| publish_messageA | Sends a notification to one or more topics. ntfy has no multi-topic publish, so this sends one request per topic and reports each outcome separately — a rejection on one topic does not discard the ones that succeeded. Check the "ok" field per entry rather than assuming the whole call worked. The returned id is also the notification's sequence id: pass it to update_message to revise this notification in place, which is how a progress report stays one notification instead of five. |
| update_messageA | Replaces the content of a notification already published, so subscribers see it change in place instead of receiving another one. The sequence id is the id returned by publish_message. It only exists for cached messages: one published with "cache": false cannot be updated. Only the fields given are sent; the cache keeps each revision as its own entry pointing back at the original, which is why list_messages shows them with an "updates" field — the original keeps its old text and a second entry carries the new one. Needs ntfy 2.16.0 or newer, and the failure below that is silent: an older server simply publishes a new notification instead of revising the old one, and answers success. If subscribers report receiving two, that is why — check get_server_info for the version. Asks a person first; where the client cannot show a dialog, call once to receive a token and again with it. |
| mark_messages_readA | Clears notifications on subscribers' devices. The messages stay in the server cache and remain readable with list_messages — that is the whole difference from delete_messages, which also leaves them there but tells subscribers to remove rather than to clear. Needs ntfy 2.16.0 or newer. Against an older server every id comes back with ok:false inside a result that is not an error — check the per-id results rather than only whether the call succeeded. |
| delete_messagesA | Deletes notifications and cancels scheduled ones that have not been delivered yet. Requires a confirmation token: call once without it to receive the token, then again with it. "Deleted" means subscribers are told to remove their copy. ntfy publishes a message_delete event and does not remove anything from its own cache, so list_messages and get_message still return the message afterwards, until it expires. Do not read that as the delete having failed, and do not delete again: the delete event is in the list too, alongside the message it refers to. Needs ntfy 2.16.0 or newer. Against an older server every id comes back with ok:false inside a result that is not an error — check the per-id results rather than only whether the call succeeded. |
| create_userA | Creates a non-admin account on a self-hosted instance. Requires an admin account. Grant it access to topics with manage_user_access — a new account can reach nothing until you do. The API cannot create administrators; only the ntfy CLI can ( Asks a person first; where the client cannot show a dialog, call once to receive a token and again with it. Be aware that a password passed as a tool argument stays in the conversation transcript. For an account that matters, create it on the server instead. |
| delete_userA | Removes an account and every access grant attached to it. Requires an admin account and a confirmation token: call once without it to receive the token, then again with it. |
| manage_user_accessA | Sets or removes an account's access to a topic or topic pattern. Requires an admin account and a confirmation token. Destructive in both directions, which is why it is gated: taking access away breaks a running publisher, and granting it exposes a topic's traffic to another account. A pattern may end in "*" to cover a family of topics. "deny" writes an explicit refusal — the only way to carve an exception out of a wildcard grant — whereas "revoke" removes the rule entirely, so a broader wildcard or the server default applies again. Where NTFY_TOPICS restricts this server, the topic must be one of its entries and a wildcard is refused: a pattern covers topics that are not on that list. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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/ni-c/ntfy-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server