What can you do with this server?

This server allows you to send customizable push notifications to your registered Pushover devices via a single send_notification tool. Parameters: * message (required): The body text of the notification. * title (optional): A custom title; defaults to your Pushover app name. * priority (optional): How insistent the alert is: * lowest — silent, no notification * low — no sound or vibration * normal — default behavior * high — bypasses quiet hours * emergency — repeats until acknowledged * sound (optional): A specific notification sound (e.g., pushover, bike, bugle, siren, magic); omit to use the device default. * url (optional): A supplementary URL to attach. * url_title (optional): A clickable label for the supplementary URL. * device (optional): Target a specific registered device by name; omit to send to all devices.

How do I use pushover-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pushover-mcp Send a push notification 'Deploy finished' with high priority to my phone" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

pushover-mcp

A tiny MCP server that sends push notifications through Pushover.

It exposes one tool:

send_notification — send a message with optional title, priority, sound, url, url_title, and device.

Two parameters are designed to read well to an LLM:

priority uses names instead of numbers: lowest, low, normal (default), high, emergency (repeats until acknowledged).
sound is an allowlist fetched live from Pushover's sounds API once at startup and cached for the process. If that fetch fails (offline, or no token), it falls back to a baked-in list so the server still starts.

Setup

Get your user key from your Pushover dashboard and create an application to get an API token at https://pushover.net/apps/build.
Install dependencies:
```
uv sync
```

Related MCP server: mcp-gotify

Run

The server reads PUSHOVER_TOKEN and PUSHOVER_USER from the environment.

With 1Password (recommended)

.env holds secret references (op://…), not the secrets themselves. Launch through op run to resolve them at runtime:

op run --env-file=.env -- uv run pushover_mcp.py

With plain env vars

PUSHOVER_TOKEN=... PUSHOVER_USER=... uv run pushover_mcp.py

Use with Claude Code / Claude Desktop

Launching via op run keeps secrets out of the MCP config entirely:

claude mcp add pushover -- \
  op run --env-file=/Users/charlesbine/Documents/prog/mcp/pushover/.env -- \
  uv run --directory /Users/charlesbine/Documents/prog/mcp/pushover pushover_mcp.py

Or as JSON (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "pushover": {
      "command": "op",
      "args": [
        "run", "--env-file=/Users/charlesbine/Documents/prog/mcp/pushover/.env", "--",
        "uv", "run", "--directory", "/Users/charlesbine/Documents/prog/mcp/pushover", "pushover_mcp.py"
      ]
    }
  }
}

Tests

uv run pytest

Tests mock the network and use no real credentials, so they run offline. Run them with plain uv run pytest (not via op run) so the import-time sound fetch falls back instead of calling the live API. GitHub Actions runs the suite on every push and pull request across Python 3.10–3.13 (see .github/workflows/ci.yml).

Run over HTTP (Docker)

The server speaks stdio by default. Set MCP_TRANSPORT=streamable-http to serve over Streamable HTTP instead, so any HTTP-capable MCP client can connect at http://<host>:8000/mcp. The Docker image sets this for you.

docker build -t pushover-mcp .
docker run --rm -e PUSHOVER_TOKEN -e PUSHOVER_USER -p 8000:8000 pushover-mcp

As a Compose service — credentials live in this container's own environment (an env_file or Docker secrets), so they stay isolated to this tool:

services:
  pushover-mcp:
    build: .
    environment:
      PUSHOVER_TOKEN: ${PUSHOVER_TOKEN}
      PUSHOVER_USER: ${PUSHOVER_USER}
    restart: unless-stopped

The HTTP endpoint is unauthenticated, so don't expose it publicly — keep it on a private/internal network (and drop the published ports: if a co-located client reaches it over the Compose network).

License

MIT © Charles Bine

Available Tools

1 tool

send_notificationA

Send a push notification via Pushover to your registered devices.

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	The notification body text.
`title`	No	Message title; defaults to your app name in Pushover.
`priority`	No	How insistent the alert is: 'lowest' (silent, no notification), 'low' (no sound/vibration), 'normal' (default), 'high' (bypasses quiet hours), 'emergency' (repeats until acknowledged).	normal
`sound`	No	Notification sound; omit to use the device default.
`url`	No	A supplementary URL shown with the message.
`url_title`	No	A clickable title for the supplementary URL.
`device`	No	Target a specific device by name; omit to send to all.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It merely states the action without mentioning side effects (e.g., actual push notification dispatch, potential costs or rate limits), failure behavior, or authentication needs. This leaves the agent underinformed.

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 a single, concise sentence with no wasted words. It is front-loaded with the core action.

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?

The tool has 7 parameters (all documented in schema) and an output schema, so description need not explain return values. However, the description lacks context about real-world impact (e.g., sending actual notifications). It is functional but minimally complete.

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 coverage is 100%, and the description adds no parameter details beyond what the schema provides. Baseline 3 is appropriate as the schema already documents all parameters.

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 verb 'send', the resource 'push notification', the service 'Pushover', and the target 'your registered devices'. It is specific and informative, distinguishing the tool as a notification sender without needing sibling differentiation.

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

Usage Guidelines3/5

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

No sibling tools exist to differentiate, and the description does not provide explicit guidance on when to use this tool or prerequisites (e.g., Pushover account). The usage is implied by the purpose, but no contextual direction is given.

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.

1 tool updatev0.1.0Jun 18, 2026
- First observedsend_notification

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-06-18 15:30 across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools.

Naming Consistency5/5

With a single tool, naming is trivially consistent.

Tool Count5/5

A single tool is appropriate for a focused server that sends push notifications via Pushover.

Completeness4/5

The tool covers the primary action of sending notifications, but lacks secondary features like delivery status or recipient management, which are minor gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp-serverOAuth
net.vybit
Push notifications with personalized sounds - manage and trigger your vybits via MCP
App Automation Communication
2
kweenkl-mcp A
io.github.antoinedelorme
Push notifications for AI agents - send instant iPhone notifications from any MCP client.
Communication App Automation
62
mcp-fishOAuth
io.github.AceDataCloud
MCP server exposing the AceDataCloud Fish Audio API (text-to-speech with voice conditioning)
Text-to-Speech Speech Processing
21
GRACE Hello MCP A
io.github.rajitharul
A very simple remote MCP server that greets you, with a custom icon.
Developer Tools
2

Related MCP Servers

apple-notifier-mcp
OS Automation Text-to-Speech App Automation
turlockmike
A
license
A
quality
C
maintenance
A simple MCP server that can send notifications on mac devices.
Updated 8 months ago (2026-01-21 16:35 UTC)
5
8 npm
26
MIT
mcp-gotify
Communication
fastmcp-me
A
license
B
quality
D
maintenance
MCP server for sending Gotify push notifications to your devices.
Updated a year ago (2025-10-10 18:54 UTC)
1
MIT
MCPal
Developer Tools Workplace & Productivity
mjkid221
A
license
A
quality
C
maintenance
A lightweight MCP server that enables sending native desktop notifications with action buttons and text replies, compatible with any MCP client.
Updated 7 months ago (2026-02-09 22:10 UTC)
1
7 npm
1
MIT
ntfy-mcp
Communication
Edqe14
A
license
C
quality
D
maintenance
MCP server for sending notifications to ntfy.sh or self-hosted ntfy instances.
Updated 5 months ago (2026-04-08 10:32 UTC)
2
7 npm
MIT

pushover-mcp

Setup

Run

With 1Password (recommended)

With plain env vars

Use with Claude Code / Claude Desktop

Tests

Run over HTTP (Docker)

License

Available Tools

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

apple-notifier-mcp

mcp-gotify

MCPal

ntfy-mcp