Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Jon's Pushover MCP Server send a notification that says 'Meeting starts in 5 minutes' with title 'Team Standup'"
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.
An MCP server for sending push notifications via Pushover.
Python 3.10+
Pushover account with API token and user key
Related MCP server: MCP-Pushover Bridge
Variable | Required | Description |
| Yes | Application API token from https://pushover.net/apps |
| Yes | User key from https://pushover.net |
# Clone the repository
git clone <your-repo-url>
cd jons-mcp-pushover
# Install with uv
uv pip install -e .uv run jons-mcp-pushoverAdd this to your Claude Desktop config file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"pushover": {
"command": "uv",
"args": ["run", "--project", "/path/to/jons-mcp-pushover", "jons-mcp-pushover"],
"env": {
"PUSHOVER_API_TOKEN": "your-api-token-here",
"PUSHOVER_USER_KEY": "your-user-key-here"
}
}
}
}# Register the MCP server with Claude Code
claude mcp add jons-mcp-pushover \
-e PUSHOVER_API_TOKEN=your-api-token-here \
-e PUSHOVER_USER_KEY=your-user-key-here \
-- uv run --directory /path/to/jons-mcp-pushover jons-mcp-pushoversend_notificationSend a push notification to your devices.
Parameter | Type | Required | Default | Description |
| string | Yes | - | The notification message body |
| string | No | App name | Title shown at top of notification |
| string | No | - | URL to include (tappable in notification) |
| string | No | - | Label for the URL |
| integer | No | 0 | Priority: -2 (silent) to 2 (emergency) |
| string | No | device default | Notification sound name |
Example:
send_notification(
message="Build completed successfully!",
title="CI Pipeline",
url="https://github.com/user/repo/actions",
url_title="View Build",
priority=1,
sound="magic"
)# Install with dev dependencies
uv pip install -e ".[dev]"# Run all tests
uv run pytest
# Run with coverage
uv run pytest --cov=src
# Run a specific test
uv run pytest tests/test_pushover.py::test_send_notification_success# Type check
uv run mypy src/jons_mcp_pushover
# Format code
uv run black src tests
# Lint code
uv run ruff check src testsjons-mcp-pushover/
├── src/
│ ├── __init__.py
│ └── jons_mcp_pushover/
│ ├── __init__.py # Package exports
│ ├── constants.py # Configuration constants
│ ├── exceptions.py # Custom exceptions
│ ├── utils.py # Utility functions
│ ├── server.py # FastMCP server setup
│ └── tools/
│ ├── __init__.py # Tool exports
│ └── pushover.py # Pushover notification tool
├── tests/
│ ├── conftest.py # Test fixtures
│ └── test_pushover.py # Pushover tool tests
├── pyproject.toml # Project configuration
├── CLAUDE.md # AI assistant guidance
└── README.md # This fileCreate a new file in src/jons_mcp_pushover/tools/ or add to an existing file
Write an async function with type hints and a docstring:
async def my_tool(param: str) -> str:
"""Brief description for the MCP tool listing.
Args:
param: What this parameter does.
Returns:
What the tool returns.
"""
return f"Result: {param}"Export from src/jons_mcp_pushover/tools/__init__.py
Register in server.py with mcp.tool(my_tool)
MIT
Send a push notification via Pushover.
Args: message: The notification message body (required). title: Title shown at top of notification. Defaults to app name. url: URL to include (tappable in notification). url_title: Label for the URL instead of showing raw URL. priority: Priority level from -2 (silent) to 2 (emergency). Default 0. sound: Notification sound name. See Pushover docs for available sounds.
Returns: Dictionary with 'status' (1 for success) and 'request' (UUID string).
Raises: ValueError: If priority is out of range or sound is invalid. PushoverError: If Pushover API returns an error or credentials are missing.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| title | No | ||
| url | No | ||
| url_title | No | ||
| priority | No | ||
| sound | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it explains the return format (dictionary with status and request UUID), error conditions (ValueError for invalid inputs, PushoverError for API/credential issues), and default values for parameters. It doesn't mention rate limits, authentication requirements, or notification delivery guarantees.
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 well-structured with clear sections (Args, Returns, Raises), front-loaded with the core purpose, and every sentence adds value. No redundant information or fluff - each parameter explanation is necessary and concise.
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 no annotations, 6 parameters with 0% schema coverage, and an output schema present, the description does very well. It explains parameters thoroughly, documents return values and errors. Minor gap: doesn't mention authentication/credential setup or rate limits, which would be helpful for a notification-sending tool.
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 fully. It provides excellent parameter semantics: explains each parameter's purpose, indicates required vs. optional, provides default values, explains priority range (-2 to 2), and references external documentation for sounds. This adds substantial meaning beyond the bare schema.
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 tool's purpose with specific verb ('Send') and resource ('push notification via Pushover'), and distinguishes it from any alternatives by specifying the service provider. The first sentence directly answers 'what does this tool do?' without ambiguity.
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 provides implied usage context through parameter explanations (e.g., priority levels, URL inclusion) but doesn't explicitly state when to use this tool versus alternatives. Since there are no sibling tools mentioned, the lack of explicit comparison is less critical, but no guidance on prerequisites or typical use cases is provided.
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.0send_notificationScored across 1 tool
With only one tool, there is no possibility of confusion or overlap between tools. The tool 'send_notification' has a clear, singular purpose that is distinct by default.
The single tool name 'send_notification' follows a clear verb_noun pattern, and with only one tool, consistency is inherently perfect as there are no other names to compare against.
A single tool is too few for most server purposes, as it limits functionality and suggests a thin or incomplete surface. For a notification service, basic operations like listing or managing notifications might be expected, but only sending is provided.
The server's domain appears to be Pushover notifications, but it only offers a send operation. There are significant gaps, such as no ability to retrieve, update, delete, or list notifications, which could cause agent failures in broader workflows.
Push notifications for AI agents - send instant iPhone notifications from any MCP client.
Push notifications with personalized sounds - manage and trigger your vybits via MCP
Let agents send content-free push notifications to a paired phone via MCP.
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
