About notifyfan
notifyfan is an MCP server and CLI that sends notifications through an Apprise API server. It supports configured tags, all configured services, one-off Apprise URLs, and upstream health and status checks.
Key features
- 01Send to a configured tag or all services
- 02Send to one-off Apprise URLs
- 03Check server health and status
- 04Validate actions and notification types
- 05CLI and stdio server modes
Use cases
- 01Send deployment updates to an operations tag
- 02Notify configured services without a tag
- 03Send a one-off message to an Apprise URL
- 04Check Apprise API availability
MCP support
Exposes one MCP tool, `apprise`, with actions for health, status, help, and notifications through an Apprise API server. The stdio server reads its URL and optional bearer token from environment variables.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
Tools
1Saved tool list · updated 1w ago
| Parameter | Type | Required | Description |
|---|---|---|---|
| tag | string | No | Tag filter selecting which configured services receive the notification. |
| body | string | No | Notification body text, for the notify action. |
| type | enum | No | Notification type: info, success, warning, or failure.info | success | warning | failure |
| urls | string | No | Apprise URL or URLs to send to, for the notify_url action. |
| title | string | No | Notification title, for the notify action. |
| action | enum | Yes | Action to run: health, status, help, notify, or notify_url.health | status | help | notify | notify_url |
Details
From the project READMEnotifyfan
notifyfan sends notifications through an Apprise API server. A single
tool, apprise, fans a message out to the destinations Apprise is
configured with: send to one configured tag (or to every configured
service), fire a one-off send at raw Apprise URL schemas, and check
that the upstream server is alive — all through one action argument
instead of a tool per operation. One binary serves a command-line
interface and a stdio MCP server.
Configuration
Two environment variables configure the upstream connection:
APPRISE_URL— the Apprise API server base URL. Defaults tohttp://localhost:8000.APPRISE_TOKEN— optional. When the upstream requires bearer auth, set it and notifyfan sendsAuthorization: Bearer <token>on every upstream call. It is read from the environment only: it is never a CLI flag and never an MCP tool argument.
The help action works with nothing configured at all.
Install
npx @reneturcios/notifyfan health
Or run the container image:
docker run -i ghcr.io/cloudcorprecords/notifyfan
The container defaults to the MCP server. Pass CLI arguments to use it as a CLI instead.
CLI
notifyfan health
notifyfan status
notifyfan help
notifyfan notify "Deployment succeeded" --tag ops --title "Deploy complete" --type success
notifyfan notify "Standup notes are posted"
notifyfan notify-url "mailto://[email protected]" "Build finished" --type info
notifyfan --version
notify needs only a body; omit --tag to send to all configured
services. notify-url takes the Apprise URLs first (one string;
separate several URLs with commas) and then the body. Exit codes:
0 on success, 1 when a call fails (validation or upstream error),
2 for usage errors.
MCP server
npx -y @reneturcios/notifyfan mcp
MCP client configuration:
{
"mcpServers": {
"notifyfan": {
"command": "npx",
"args": ["-y", "@reneturcios/notifyfan", "mcp"],
"env": {
"APPRISE_URL": "http://localhost:8000"
}
}
}
}
Add APPRISE_TOKEN to the env block only when your Apprise API
server requires it.
Tool
| Tool | Input | What it does |
|---|---|---|
apprise | action (string, required) plus the per-action parameters below | Runs the named action against the upstream Apprise API server. |
Actions:
| Action | Required | Optional | What it does |
|---|---|---|---|
health | — | — | Check Apprise API server health. |
status | — | — | Return authenticated deployment and runtime status. |
help | — | — | Return built-in markdown tool help. Makes no upstream call. |
notify | body | tag, title, type | Send to a configured Apprise tag, or to all configured services when tag is omitted. |
notify_url | urls, body | title, type | Send a stateless one-off notification to one or more Apprise URL schemas. urls is a single string; separate multiple URLs with commas. |
type is one of info (informational), success (successful
operation), warning (non-critical warning), or failure (critical
failure or error). Unknown actions, a missing body/urls, and an
invalid type are errors raised before any upstream call.
Example call:
{
"name": "apprise",
"arguments": {
"action": "notify",
"body": "Deployment succeeded",
"tag": "ops",
"title": "Deploy complete",
"type": "success"
}
}
Upstream mapping and known gaps
The action catalogue above is the documented surface. The upstream
paths are documented reconstructions from the standard Apprise API:
notify posts {body, tag?, title?, type?} to POST /notify, and
notify_url posts {urls, body, title?, type?} to the same endpoint
— the stateless form; the upstream API has no separate /notify_url
route. health reads GET / (the upstream root) and status reads
GET /details. Payload fields that were not supplied are omitted,
never sent empty. Upstream failures surface the HTTP status plus the
upstream message or error string when one is present, and a
non-JSON success body is returned as raw text.
- The original's HTTP transport, OAuth, and
send_alertprompt are not reproduced; this rebuild is stdio-only. - No live Apprise API server was used while building: every upstream behaviour is verified against a fake fetch in the test suite.
Development
npm install
npm run build # tsc -> dist/
npm test # node test runner over test/*.test.ts, no network (fake fetch fixtures)
npm run dev # run the CLI from source via tsx
License
MIT — see LICENSE.
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.