ntfy-mcp

by ni-c

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Publish a notification

publish_message

Send a notification to one or more ntfy topics, handling each topic separately and reporting individual outcomes.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`icon`	No	URL of a JPEG or PNG icon.
`tags`	No	Tags as separate entries. Names that match an emoji short code (for example "warning", "rocket") are rendered as that emoji.
`cache`	No	Set false to keep the message out of the server cache. It then reaches only clients connected at that moment, and cannot be updated or deleted afterwards.
`click`	No	URL opened when the notification itself is tapped.
`delay`	No	Deliver later: a duration such as "30m", a Unix timestamp, or natural language like "tomorrow, 10am". Between 10 seconds and 3 days.
`title`	No	The notification title.
`attach`	No	URL of a file to attach by reference.
`topics`	No	Topics to publish to. Defaults to the first NTFY_TOPICS entry.
`actions`	No	Up to 3 action buttons. An "http" action fires from the recipient's device, not from the server, and defaults to POST.
`message`	No	The notification body.
`filename`	No	Download name for the attachment.
`firebase`	No	Set false to skip forwarding via Firebase.
`markdown`	No	Render the message as Markdown in clients that support it.
`priority`	No	1 (min) to 5 (max), or "min"/"low"/"default"/"high"/"max".

Output Schema

TableJSON Schema

Name	Required	Description
`failed`	Yes	Topics that refused it.
`results`	Yes
`published`	Yes	Topics that accepted it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.0Sep 8, 2026
- addedOutput schema / properties / results / items / properties / note
```
Added value: +{
+  "description": "Set when the publish worked but the id did not.",
+  "type": "string"
+}
```
First observedv0.2.0Sep 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description goes beyond the basic annotations by explaining partial failure behavior: one request is sent per topic, and a rejection on one topic does not discard others. It also tells the caller to check the 'ok' field per entry and explains that the returned id can be used to update the notification in place.

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

Conciseness5/5

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

The description is concise, front-loaded with the core purpose, and contains only meaningful behavioral guidance. It avoids repeating schema details while still covering the most important publishing semantics.

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

Completeness5/5

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

For a tool with a rich input schema, the description covers the key contextual aspects: multi-topic handling, partial failure, update capability, and per-parameter semantics. Since an output schema exists, the description does not need to enumerate return fields.

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

Parameters5/5

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

Every parameter has a description that adds valuable context beyond the schema. Examples include emoji rendering for tags, cache behavior implications, the 10-second to 3-day delay range, the default topics behavior, and the note that HTTP actions fire from the recipient's device.

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 that the tool sends a notification to one or more topics, using a specific verb and resource. It also distinguishes the publish action from updating or revising an existing notification via update_message.

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 gives clear context for publishing and explains how the returned id relates to update_message for subsequent updates. It does not explicitly enumerate all sibling tools or state when not to use this tool, but the primary use case is unambiguous.

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

Deploy Server