用于 ntfy.sh 通知、异步智能体消息传递和人机协作工作流的 MCP 服务器。
它为 MCP 客户端提供了一种简单的方法，无需构建自定义消息层即可向 ntfy 主题发布消息、维持实时订阅并等待回复。
当您需要以下功能时，此服务器非常有用：
来自 MCP 连接智能体的推送通知
用户与智能体之间的异步消息交换
基于 ntfy 的轻量级人工审批或回复循环
用于长时间运行工作流的简单通知通道
典型流程：
用户或外部系统向 ntfy 主题发布消息。
MCP 客户端通过 wait-and-read-inbox 或 ntfy://inbox 读取该消息。
智能体通过 send-ntfy 进行响应。
用户以 ntfy 推送通知的形式接收响应。
Related MCP server: Chat Human MCP Server
发布带有可选标题、优先级、标签和附件的消息
维持持久订阅以实现近乎实时的交付
无需重启服务器即可切换主题
将最近的消息保存在内存和磁盘中
支持 Bearer Token 和 Basic-Auth 保护的主题
开箱即用，支持公共 ntfy.sh
全局安装：
npm install -g nfty-mcp-server或通过 npx 运行：
npx -y --yes nfty-mcp-server在 ntfy.sh 上创建或重用一个主题。公共主题易于设置，因此请选择一个唯一的名称。
对于 Cursor 或 VS Code，请将其添加到您的 MCP 设置中：
{
"mcpServers": {
"nfty": {
"command": "npx",
"args": ["-y", "--yes", "nfty-mcp-server"],
"env": {
"NTFY_TOPIC": "your-topic-name",
"NTFY_BASE_URL": "https://ntfy.sh"
}
}
}
}对于 Claude Desktop，将相同的服务器条目添加到 claude_desktop_config.json 中。
注意：
NTFY_TOPIC 是必需的
--yes 将 npx 安装保留在其自己的缓存中，而不是污染项目目录
重启 Cursor、VS Code 或 Claude Desktop 以加载 MCP 服务器。
send-ntfy向配置的主题发布消息。
参数：
message 必需
title 可选
priority 可选，1 到 5
tags 可选
attachUrl 可选
示例：
{
"message": "Task completed successfully.",
"title": "Task Status",
"priority": 4
}set-ntfy-topic切换当前会话的活动主题。
参数：
topic 必需
baseUrl 可选
wait-and-read-inbox等待配置主题上的新消息，并在至少有一条消息到达时返回。
参数：
since 可选
sinceTime 可选
sinceNow 可选，默认为 true
重要提示：
许多 MCP 客户端会强制执行大约 60 秒的超时
如果您正在等待人工输入，客户端或调用智能体应在超时后重试
智能体聊天流程的推荐提示行为：
如果
wait-and-read-inbox在等待用户响应时超时，请重试直到有新消息到达。
ntfy://inbox以 JSON 格式返回配置主题的最近消息。
示例结构：
{
"topic": "your-topic",
"baseUrl": "https://ntfy.sh",
"messages": [
{
"id": "message-id",
"time": 1234567890,
"title": "Message Title",
"message": "Message body",
"priority": 3,
"tags": ["tag1"],
"topic": "your-topic"
}
]
}服务器将日志、缓存文件和锁文件存储在专用数据目录中，因此不会弄乱当前项目。
默认位置：
macOS / Linux: ~/.nfty-mcp-server/
Windows: C:\Users\<user>\.nfty-mcp-server\
写入那里的文件包括：
nfty-messages.json
nfty-debug.log
nfty-process.log
nfty.lock
变量 | 描述 | 默认值 |
| 发送/接收消息的主题 | 必需 |
| ntfy 服务器 URL |
|
| Bearer token | 可选 |
| Basic-auth 用户名 | 可选 |
| Basic-auth 密码 | 可选 |
| 初始积压游标 |
|
| 获取超时（毫秒） |
|
| 启动时清除日志/缓存 |
|
| 终止现有服务器实例 |
|
| 数据目录覆盖 | 默认平台路径 |
| 缓存文件覆盖 |
|
您也可以直接配置服务器：
npx nfty-mcp-server --topic my-topic --base-url https://ntfy.sh --auth-token your-token支持的参数：
--topic
--base-url 或 --server
--auth-token
--username
--password
--since
--log-incoming
服务器打开到配置主题的持久 HTTP 订阅。
通过该实时连接接收传入消息。
最近的消息缓存在内存中并持久化到磁盘。
MCP 工具在订阅之上公开发送、主题切换和等待/读取行为。
异步用户-智能体消息传递
长时间运行任务的推送通知
人工审批循环
轻量级操作员警报
通过共享主题进行智能体间协调
git clone https://github.com/harshwasan/NFTY-MCP.git
cd NFTY-MCP
npm install
npm test
npm run dev项目布局：
NFTY-MCP/
src/server.js
tests/server.test.js
package.json消息未到达：
验证 NTFY_TOPIC
确认主题存在且可访问
检查配置数据目录中的调试日志
连接问题：
验证对配置的 NTFY_BASE_URL 的网络访问权限
如果主题受保护，请验证身份验证设置
MIT
Publish a message to the configured ntfy topic (set in mcp.json). Supports optional title, priority (1-5), tags, and attachUrl. After sending, use wait-and-read-inbox to wait for responses.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | No | ||
| message | Yes | ||
| priority | No | ||
| attachUrl | No |
| Name | Required | Description |
|---|---|---|
| id | No | |
| time | No | |
| topic | Yes | |
| status | Yes | |
| priority | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only describes the action as 'publish' without mentioning side effects, idempotency, permission requirements, or rate limits. The description lacks transparency on common behavioral aspects for a send operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with essential information front-loaded. The first sentence establishes the core purpose, and the second provides a useful cross-reference. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be explained. The description covers the basic operation but omits potential constraints (e.g., message length, priority semantics) and error scenarios. It assumes the topic is configured in mcp.json without discussing what happens if it's not. Completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description partially compensates by listing all optional parameters and noting priority range (1-5). However, it does not explain the purpose of tags or attachUrl, nor does it provide formats or examples, leaving some semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Publish a message to the configured ntfy topic', specifying the verb and resource. It lists supported optional fields (title, priority, tags, attachUrl). This differentiates it from siblings set-ntfy-topic (configuration) and wait-and-read-inbox (response handling).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use wait-and-read-inbox after sending, providing sequential guidance. It does not discuss when not to use this tool or prerequisites, but the context is clear: it is for sending a message to a preconfigured topic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the ntfy topic for this MCP server session (no restart needed).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| baseUrl | No |
| Name | Required | Description |
|---|---|---|
| topic | Yes | |
| baseUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It only mentions 'no restart needed', but does not explain implications of changing topic mid-session, whether the change is persistent, or what happens to ongoing notifications. Lacks detail on side effects and conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action. However, it could be structured to include more detail without being wasteful; currently it is slightly under-specified for a 2-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool but fails to address the baseUrl parameter. Completeness is acceptable for a minimal tool but has a clear gap given the presence of an optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'topic' parameter implicitly but does not mention the 'baseUrl' parameter at all, leaving its purpose unclear for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Change') and resource ('ntfy topic'), specifying it is for the session and does not require restart. This distinguishes it from siblings send-ntfy and wait-and-read-inbox, which are about message sending and receiving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (changing topic in session) but does not explicitly state when to use compared to siblings or when not to use it. 'No restart needed' hints at immediate effect but lacks comprehensive guidance on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Waits for new messages on the configured topic (set in mcp.json) and returns when a new message arrives. Does not return until at least one new message is received. Uses the existing subscription. Note: The MCP protocol has a ~60s client-side timeout that cannot be controlled from the server, but this tool will wait as long as possible within that limit.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Cursor to filter messages after this point | |
| sinceNow | No | If true (default), only returns messages sent after this call starts. If false, returns all messages since the cursor. | |
| sinceTime | No | Unix timestamp - filter messages with time >= sinceTime |
| Name | Required | Description |
|---|---|---|
| messages | Yes | |
| newCount | Yes | |
| lastCursor | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it waits indefinitely (subject to timeout), uses existing subscription, and returns only on new message. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core function, each providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's waiting behavior and 3 parameters, the description covers the key aspects including timeout and return condition. Output schema exists, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the input schema already describes for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (wait for new messages) and resource (inbox on configured topic), and distinguishes from siblings (send-ntfy, set-ntfy-topic) which are different tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool blocks until a new message arrives and notes the client-side timeout, providing clear usage context. However, it does not explicitly state when not to use it or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.35send-ntfyset-ntfy-topicwait-and-read-inboxScored across 3 tools
Each tool serves a distinct purpose: sending messages, changing topic, and waiting for incoming messages. No overlap, clear boundaries.
Tool names mix patterns: 'send-ntfy' and 'set-ntfy-topic' use verb-ntfy, but 'wait-and-read-inbox' uses a different structure with 'and'. Inconsistent naming conventions.
Three tools is appropriate for a focused notification server: send, configure topic, and receive. Each tool is necessary and none are redundant.
Core publish/subscribe functionality is covered with send and wait. The set-topic tool adds flexibility. A minor gap is lack of explicit unsubscribe or message history, but not essential for core use.
Push notifications for AI agents - send instant iPhone notifications from any MCP client.
Reach your own phone from an AI agent: notifications, approval questions, reminders, ring, files.
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Zero-setup WhatsApp notifications + human-in-the-loop for AI agents — text 'join', send in 60s.
