Skip to main content
Glama
deenesjakoruzh
gitmotion

ntfy-me-mcp

by gitmotion
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

ntfy-me-mcp

TypeScript Model Context Protocol NPM Version Docker Image Version License GitHub

A streamlined Model Context Protocol (MCP) server for sending notifications via ntfy service (public or selfhosted with token support) 📲

Overview

ntfy-me-mcp provides AI assistants with the ability to send real-time notifications to your devices through the ntfy.sh service (either public or selfhosted with token support). Get notified when your AI completes tasks, encounters errors, or reaches important milestones - all without constant monitoring.

The server includes intelligent features like automatic URL detection for creating view actions and smart markdown formatting detection, making it easier for AI assistants to create rich, interactive notifications without extra configuration.

Related MCP server: ntfy-mcp-server

Features

  • 🚀 Quick Setup: Run with npx or docker!

  • 🔔 Real-time Notifications: Get updates on your phone/desktop when tasks complete

  • 🎨 Rich Notifications: Support for topic, title, priorities, emoji tags, and detailed messages

  • 🔍 Notification Fetching: Fetch and filter cached messages from your ntfy topics

  • 🎯 Smart Action Links: Automatically detects URLs in messages and creates view actions

  • 📄 Intelligent Markdown: Auto-detects and enables markdown formatting when present

  • 🔒 Secure: Optional authentication with access tokens

  • 🔑 Input Masking: Securely store your ntfy token in your vs config!

  • 🌐 Self-hosted Support: Works with both ntfy.sh and self-hosted ntfy instances

Coming soon...

  • 📨 Email: Send notifications to email (requires ntfy email server configuration)

  • 🔗 Click urls: Ability to customize click urls

  • 🖼️ Image urls: Intelligent image url detection to automatically include image urls in messages and notifications

  • 🏁 and more!

Table of Contents

Quickstart - MCP Server Configuration

Choose the config shape that matches your client. All examples below use NTFY_TOPIC as the required variable and keep the optional auth settings commented out until you need them.

Configuration Examples

Installation

If you need to install and run the server directly (alternative to the MCP configuration above):

Setting Up the Notification Receiver

  1. Install the ntfy app on your device

  2. Subscribe to your chosen topic (the same as your NTFY_TOPIC setting)

Configuration

Environment Variables

Create a .env file by copying the example: cp .env.example .env — see .env.example for reference.

Variable

Required

Default

Description

NTFY_TOPIC

Yes

—

The ntfy topic to publish notifications to

NTFY_URL

No

https://ntfy.sh

ntfy server URL — change this for self-hosted instances(include port if needed, e.g. https://your-server.com:8443)

NTFY_TOKEN

No

—

Access token for protected topics or private servers

Authentication

This MCP server supports both authenticated and unauthenticated ntfy endpoints:

  • Public Topics: When using public topics on ntfy.sh or other public servers, no authentication is required.

  • Protected Topics:

    • For protected topics or private servers, you need to provide an access token via NTFY_TOKEN env variable or in the accessToken parameter of the tool.

    • If authentication is required but not provided, you'll receive a clear error message explaining how to add your token.

Secure Token Handling (vscode)

  • If your client supports prompt-based secret inputs (i.e. VS Code), prefer that over hardcoding NTFY_TOKEN in config files. (Otherwise use your token directly)

  • Use matching values like this in your mcp.json file:

// Add this to your VS Code `mcp.json` file, either the user-level file or your workspace `.vscode/mcp.json`
// Set `NTFY_TOKEN` exactly to `"${input:ntfy_token}"` when you want VS Code to treat it as a secure prompt-backed value.

{
  "inputs": [
    {
      "type": "promptString",
      "id": "ntfy_token",
      "description": "Ntfy Token",
      "password": true
    }
  ],
  "servers": {
    "ntfy-me-mcp": {
      "command": "npx",
      "args": ["-y", "ntfy-me-mcp"],
      "env": {
        "NTFY_TOPIC": "your-ntfy-topic",
        "NTFY_URL": "https://your-ntfy-server.com",
        "NTFY_TOKEN": "${input:ntfy_token}"
      }
    }
  }
}

Field

Value

Purpose

env.NTFY_TOKEN

"${input:ntfy_token}"

References the secure prompt-backed token value

inputs[].id

"ntfy_token"

Defines the input name used by NTFY_TOKEN

inputs[].type

"promptString"

Prompts the user for the token at runtime

If the client resolves "${input:ntfy_token}" before launch, the server receives the real token directly. If the placeholder is passed through unchanged, ntfy-me-mcp detects that unresolved input reference and prompts for the token itself at startup.

Since v1.4.0+, the PROTECTED_TOPIC env has been removed. This handling is now auto-detected from the unresolved NTFY_TOKEN input reference instead.

Tools & Usage

ntfy_me: Sending Notifications

Using Natural Language

  • When working with your AI assistant, you can use natural phrases to request notifications:

"ntfyme with a summary of the task when complete"
"Send me a notification when the build is complete"
"Notify me when the task is done"
"Alert me after generating the code"
"Message me when the process finishes"
"Send an alert with high priority"

Example Usage

Message Parameters

ntfy_me_fetch: Polling Notifications

Using Natural Language

AI assistants understand various ways to request message fetching:

"Show me my recent notifications"
"Get messages from the last hour"
"Find notifications with title 'Build Complete'"
"Search for messages with the test_tube tag"
"Show notifications from the updates topic from the last 24hr"
"Check my latest alerts"

Example Usage

Fetch Parameters

Development & Contributions

Contributions are welcome! Please see CONTRIBUTING.md, which include general guidelines, setup steps, etc.

License

This project is licensed under the GNU General Public License v3.0 - see the LICENSE file for details.

Made with ❤️ by gitmotion

Available Tools

2 tools
ntfy_meSend ntfy notificationA

Send a notification to the user via ntfy. Use this tool when the user asks to 'send a notification', 'notify me', 'send me an alert', 'message me', 'ping me', or any similar request. This tool is perfect for sending status updates, alerts, reminders, or notifications about completed tasks.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesNotification title/status
messageYesNotification message/body
urlNoOptional custom ntfy URL (defaults to NTFY_URL env var or https://ntfy.sh)
topicNoOptional custom ntfy topic (defaults to NTFY_TOPIC env var)
accessTokenNoOptional access token for authentication (defaults to NTFY_TOKEN env var)
priorityNoMessage priority leveldefault
tagsNoTags for the notification
markdownNoWhether to format the message with Markdown support
actionsNoOptional array of view actions to add to the notification

TDQS

A3.8/5.0
Behavior3/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 describes the basic function (sending a notification) and lists features like priority and tags, but it does not mention success/error behavior, blocking, or network requirements. This is adequate but not thorough.

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: three sentences that cover the tool's purpose, usage triggers, and suitable use cases. It is front-loaded and no sentence is wasted.

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

Completeness3/5

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

Given 9 parameters, no output schema, and no annotations, the description could be more complete. It explains the tool's function and gives usage context, but it omits details about return values or error handling. However, the schema fully describes the parameters, so the description is not severely lacking.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra context beyond the parameter descriptions in the schema, such as noting that the URL defaults to an environment variable. It does not provide additional parameter semantics.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Send a notification to the user via ntfy.' It lists example user prompts, making the purpose unmistakable. This effectively distinguishes it from the sibling tool 'ntfy_me_fetch', which likely fetches notifications.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool: 'Use this tool when the user asks to send a notification...' and lists several example phrases. It also mentions suitability for status updates, alerts, etc. However, it does not provide guidance on when not to use it or compare with alternatives.

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

ntfy_me_fetchFetch ntfy messagesA

Fetch cached messages from an ntfy server topic. Use this tool when the user asks to 'show notifications', 'get my messages', 'show my alerts', 'find notifications', 'search notifications', or any similar request. Great for finding recent notifications, checking message history, or searching for specific notifications by content, title, tags, or priority.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoOptional custom ntfy server URL (defaults to NTFY_URL env var or https://ntfy.sh)
topicNoOptional custom ntfy topic/channel to get messages from (defaults to NTFY_TOPIC env var)
accessTokenNoOptional access token for authentication (defaults to NTFY_TOKEN env var)
sinceNoHow far back to retrieve messages: timespan (e.g., '10m', '1h', '1d'), timestamp, message ID, or 'all' for all messages. Default: 10 minutes
messageIdNoFind a specific message by its ID
messageTextNoFind messages containing this exact text content
messageTitleNoFind messages with this exact title/subject
prioritiesNoFind messages with specific priority levels (min, low, default, high, max)
tagsNoFind messages with specific tags (e.g., 'error', 'warning', 'success')

TDQS

A3.9/5.0
Behavior3/5

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

No annotations provided. Description indicates a read-only fetch operation and mentions default parameter sources. Lacks details on rate limits, authentication requirements beyond token, or error handling, but basic transparency is present.

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?

Description is four sentences with front-loaded main purpose and clear structure. Could be slightly more concise but is efficient overall.

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

Completeness4/5

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

Covers purpose, usage scenarios, and parameter defaults. No output schema, so return values are implicit. Additional context like output format would improve completeness, but it's adequate for the tool's simplicity.

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

Parameters3/5

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

Input schema has 9 parameters with 100% description coverage. The description adds context about defaults and usage but does not significantly go beyond the schema's own parameter descriptions, so baseline score of 3 is appropriate.

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

Purpose5/5

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

Clearly states the verb 'Fetch' and the resource 'cached messages from an ntfy server topic'. Provides specific example user requests, distinguishing from sibling tool (ntfy_me).

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

Usage Guidelines4/5

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

Explicitly lists when to use this tool with example phrases like 'show notifications' and 'get my messages'. Does not state when not to use or alternatives, but given only one sibling, the guidance is sufficient.

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. Dates show when Glama detected each change.

  1. 2 tool updatesv1.4.2
    • Addedntfy_me
    • Addedntfy_me_fetch
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one sends notifications, the other retrieves cached messages. There is no overlap or ambiguity in their functions.

Naming Consistency4/5

Both tools share the prefix 'ntfy_me_', but the first tool lacks a specific verb suffix (e.g., 'send') while the second has '_fetch'. The pattern is mostly consistent but has a minor deviation.

Tool Count4/5

With only two tools, the set is minimal but appropriate for the narrow scope of sending and fetching notifications. It feels slightly thin but not unreasonable for a simple domain.

Completeness3/5

The tool set covers the basic operations of sending and retrieving notifications, but lacks additional expected functionality such as deleting or managing topics, leaving some gaps for full lifecycle management.

Maintenance

ActivityInactive
ResponsivenessResponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • ntfy-mcp

    teddyzxcv
    A
    license
    Not graded
    quality
    D
    maintenance
    The MCP server that keeps you informed by sending the notification on phone using ntfy.sh
    1,025
    44
    Apache 2.0

  • ntfy-mcp-server

    cyanheads
    A
    license
    Not graded
    quality
    A
    maintenance
    A Model Context Protocol server enabling AI systems to send real-time notifications to phones, desktops, and other devices through the ntfy publish/subscribe service.
    1,025
    20
    Apache 2.0

  • MCP Discord Agent

    EugenEistrach
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables AI agents to send notifications and request user input via Discord during long-running tasks. It allows users to remotely interact with their AI assistants and provide feedback through the Discord messaging platform.
    26
    2
    MIT

  • ntfy-mcp

    Edqe14
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for sending notifications to ntfy.sh or self-hosted ntfy instances.
    19
    MIT

Latest Blog Posts

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/gitmotion/ntfy-me-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server