Which integrations are available for this server?

Allows sending notifications to ntfy.sh or self-hosted ntfy instances via MCP tools, supporting various options like title, priority, tags, markdown, click action, icon, and delay.

How do I use ntfy-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ntfy-mcp Notify me when the backup completes" 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.

ntfy-mcp

by Edqe14

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

ntfy-mcp

Standalone MCP server for sending notifications to ntfy.sh or any self-hosted ntfy instance.

This server is reusable across MCP clients. It exposes tools for sending notifications, while keeping the ntfy URL and topic locked at server startup so agents cannot override them per call.

Features

stdio MCP server for broad client compatibility
locked ntfy base URL and topic
startup config via flags or environment variables
bearer token or basic auth support
ntfy_publish tool for general notifications
ntfy_ping tool for simple "finished working" notifications

Related MCP server: mcp-gotify

Install

Local development

npm install
npm run build

Published CLI

After publishing, clients can run the server directly with npx:

npx -y ntfy-mcp --ntfy-url https://ntfy.sh --ntfy-topic my-topic

Smoke test

You can run a local MCP-level smoke test after building:

node scripts/smoke-test.mjs dist/index.js \
  --ntfy-url https://ntfy.sh \
  --ntfy-topic my-test-topic

Configuration

Flags take priority over environment variables.

Flags

node dist/index.js \
  --ntfy-url https://ntfy.sh \
  --ntfy-topic my-topic \
  --ntfy-token tk_your_token

Environment variables

export NTFY_URL="https://ntfy.sh"
export NTFY_TOPIC="my-topic"
export NTFY_TOKEN="tk_your_token"
node dist/index.js

Supported variables:

NTFY_URL
NTFY_TOPIC
NTFY_TOKEN
NTFY_USERNAME
NTFY_PASSWORD

If both token auth and basic auth are configured, token auth wins.

Tool reference

`ntfy_publish`

Sends a notification to the configured topic.

Input:

{
  "message": "Deployment complete",
  "title": "Deploy",
  "priority": "high",
  "tags": ["rocket", "white_check_mark"],
  "markdown": false,
  "click": "https://example.com/deploys/123",
  "icon": "https://example.com/icon.png",
  "delay": "10m"
}

`ntfy_ping`

Convenience tool for simple pings.

Input:

{
  "message": "Agent finished working.",
  "title": "Agent finished",
  "priority": "default",
  "tags": ["robot_face", "white_check_mark"]
}

npm publish

This package is set up to publish as a public npm CLI.

npm login
npm publish

Quick checks before publishing:

npm run build
npm pack --dry-run

skills.sh skill

This repository also contains a reusable skill in the skills/ directory:

skills/ntfy-after-task/SKILL.md

After pushing the repo, it can be installed through skills.sh with:

npx skills add Edqe14/ntfy-mcp@ntfy-after-task

OpenCode

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ntfy": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "ntfy-mcp",
        "--ntfy-url",
        "https://ntfy.sh",
        "--ntfy-topic",
        "my-topic"
      ]
    }
  }
}

This only makes the tool available. To send a ping after the agent finishes working, OpenCode still needs a plugin, hook, or workflow that calls ntfy_ping when the session becomes idle or reaches your chosen completion event.

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "ntfy": {
      "command": "npx",
      "args": [
        "-y",
        "ntfy-mcp",
        "--ntfy-url",
        "https://ntfy.sh",
        "--ntfy-topic",
        "my-topic"
      ]
    }
  }
}

Cursor

Add to .cursor/mcp.json or ~/.cursor/mcp.json:

{
  "mcpServers": {
    "ntfy": {
      "command": "npx",
      "args": [
        "-y",
        "ntfy-mcp",
        "--ntfy-url",
        "https://ntfy.sh",
        "--ntfy-topic",
        "my-topic"
      ]
    }
  }
}

Notes

The server publishes with HTTP POST to https://<ntfy-host>/<topic>.
ntfy URL and topic are intentionally locked at startup.
Per-call overrides for URL or topic are not supported.
Use console.error for logs because stdout is reserved for MCP protocol traffic.

Available Tools

2 tools

ntfy_pingSend finished-work pingC

Send a simple notification to the server-configured ntfy topic.

ParametersJSON Schema

Name	Required	Default
`icon`	No
`tags`	No
`click`	No
`delay`	No
`title`	No	Agent finished
`message`	No	Agent finished working.
`markdown`	No
`priority`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`topic`	Yes
`status`	Yes
`responseText`	Yes

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It reveals that the topic is server-configured, which is useful, but it does not mention side effects, return behavior, defaults, or what 'simple' means relative to the full parameter set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with no wasted words. It earns its place, though it is arguably too sparse to carry the full informational burden.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with eight optional parameters, a sibling tool, and no annotations, the description is incomplete. It does not explain default behavior, how this differs from ntfy_publish, or what an agent should expect when invoking it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no parameter-level meaning. None of the eight parameters are mentioned or explained, leaving the agent to rely entirely on property names and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: send a notification to the server-configured ntfy topic. The title 'Send finished-work ping' adds a useful completion context. However, it does not explicitly distinguish this tool from the sibling ntfy_publish.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use ntfy_ping versus ntfy_publish. The title and the word 'simple' imply a finished-work notification, but the description does not state conditions, exclusions, or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ntfy_publishPublish ntfy notificationC

Send a notification to the server-configured ntfy topic.

ParametersJSON Schema

Name	Required	Description	Default
`icon`	No
`tags`	No
`click`	No
`delay`	No
`title`	No
`message`	Yes
`markdown`	No
`priority`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`topic`	Yes
`status`	Yes
`responseText`	Yes

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits itself, but it only restates the action and the fact that the topic is server-configured. It does not mention potential side effects beyond the obvious send, rate limits, authentication requirements, failure behavior, or delivery guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler, so it is concise in form. However, it is too terse for a tool with eight parameters and zero schema descriptions, making it under-specified rather than appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description establishes the fixed server-configured topic, which is useful context, but it leaves almost everything else unexplained. Parameter semantics, optional field behavior, priority enum values, delay syntax, and operational constraints are missing, so an agent cannot confidently use the tool beyond sending a basic message.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description mentions none of the eight parameters. The agent gets no guidance on message semantics, priority values, delay format, markdown behavior, tags, icon, click, or title, so the parameter meaning is entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Send a notification') and the resource ('server-configured ntfy topic'), so the core purpose is unambiguous. However, it does not explicitly distinguish the tool from its sibling ntfy_ping, missing the opportunity for full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided: the description does not say when to use this tool instead of ntfy_ping, when a notification is appropriate, or what prerequisites might apply. An agent must infer usage solely from the tool name and title.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.1.0Sep 6, 2026
- First observedntfy_ping
- First observedntfy_publish

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.5/5.0

Scored 2026-09-06 12:25 across 2 tools

Disambiguation1/5

Both tools perform the same action—sending a notification to the server-configured topic. The only distinction is 'simple' vs. regular, which is not meaningful enough for an agent to reliably choose between them.

Naming Consistency4/5

Both tools follow a consistent ntfy_verb pattern with snake_case, which is predictable. Minor deviation is that 'publish' and 'ping' are synonymous verbs for notification delivery.

Tool Count3/5

Two tools is borderline for a notification-focused server, but one is essentially redundant, making the count feel padded. A single publish tool would be more appropriate.

Completeness2/5

The domain is ntfy notifications, but the server only covers sending. There is no tool for subscription, topic management, or retrieving notification history, leaving significant gaps beyond the core publish action.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
SupabaseOAuth
com.supabase
MCP server for interacting with the Supabase platform
Cloud Platforms Databases Developer Tools
32,904
Manto — 馒头新闻 B
io.github.tans
Publish, search, and promote time-sensitive news and messages through a public remote MCP server.
Search Communication
101
mcp-serverOAuth
com.ffmpeg-micro
MCP server for the FFmpeg Micro video transcoding API — create, monitor, download transcodes.
Multimedia Processing App Automation
21

Related MCP Servers

ntfy-mcp
Communication
teddyzxcv
A
license
Not graded
quality
D
maintenance
The MCP server that keeps you informed by sending the notification on phone using ntfy.sh
Updated a year ago (2025-03-25 01:28 UTC)
774 npm
44
Apache 2.0
mcp-gotify
Communication
fastmcp-me
A
license
B
quality
D
maintenance
MCP server for sending Gotify push notifications to your devices.
Updated a year ago (2025-10-10 18:54 UTC)
1
MIT
mcp-ntfy
Communication Developer Tools
mambucodev
A
license
Not graded
quality
D
maintenance
MCP server for ntfy push notifications. Send and poll notifications from any MCP-compatible client.
Updated 4 months ago (2026-05-23 14:00 UTC)
7 npm
MIT
Simple Ntfy MCP Server
Communication
Aaryan-Kapoor
A
license
B
quality
D
maintenance
A lightweight MCP server for sending push notifications via ntfy.sh, supporting customizable titles, priorities, tags, and action buttons.
Updated 8 months ago (2025-12-29 21:10 UTC)
1
9 npm
7
MIT

ntfy-mcp

Features

Install

Local development

Published CLI

Smoke test

Configuration

Flags

Environment variables

Tool reference

ntfy_publish

ntfy_ping

npm publish

skills.sh skill

OpenCode

Claude Desktop

Cursor

Notes

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

ntfy-mcp

mcp-gotify

mcp-ntfy

Simple Ntfy MCP Server

`ntfy_publish`

`ntfy_ping`