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
タイトル、優先度、タグ、添付ファイル付きのメッセージ公開
ほぼリアルタイム配信のための永続的なサブスクリプションの維持
サーバーを再起動せずにトピックを切り替え可能
最近のメッセージをメモリおよびディスク上に保持
ベアラートークンおよび基本認証で保護されたトピックのサポート
公開されているntfy.shですぐに使用可能
グローバルにインストール：
npm install -g nfty-mcp-serverまたはnpx経由で実行：
npx -y --yes nfty-mcp-serverntfy.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設定されたトピックで新しいメッセージを待機し、少なくとも1つ到着したときに返します。
パラメータ：
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 |
|
| ベアラートークン | オプション |
| 基本認証ユーザー名 | オプション |
| 基本認証パスワード | オプション |
| 初期バックログカーソル |
|
| フェッチタイムアウト（ミリ秒） |
|
| 起動時にログ/キャッシュをクリア |
|
| 既存のサーバーインスタンスを終了 |
|
| データディレクトリのオーバーライド | デフォルトのプラットフォームパス |
| キャッシュファイルのオーバーライド |
|
サーバーを直接設定することもできます：
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.
