MCPal
Sends native desktop notifications with action buttons and text replies, featuring a custom OpenAI icon for Codex, OpenAI, and ChatGPT clients.
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., "@MCPalSend a notification: 'Build finished successfully' with title 'CI/CD'"
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.
Usage
Add to your MCP Config manually:
// JSON
{
"mcpServers": {
"mcpal": {
"command": "npx",
"args": ["mcpal@latest"]
}
}
}Or TOML (Codex):
// TOML
[mcp_servers.mcpal]
command = "npx"
args = ["-y", "mcpal@latest"]Codex CLI
Add MCPal directly via the CLI:
codex mcp add mcpal -- npx -y mcpal@latestClaude Code
Add MCPal directly via the CLI:
# Project scope (current project only)
claude mcp add mcpal -- npx -y mcpal@latest
# User scope (available in all projects)
claude mcp add mcpal --scope user -- npx -y mcpal@latestConfiguring Proactive Notifications
MCPal includes built-in MCP instructions that tell clients how to use notifications. To configure when your assistant should proactively notify you, add this to your client instruction file. This should either be AGENTS.md or CLAUDE.md based on your model:
## Post Task Completion Hook
ALWAYS use MCPal MCP tool (if available) to notify me when you finish any tasks (this includes reading files, investigating, coding). You should use this tool before you terminate conversations. Refer to tool instructions precisely to craft your response.Customize this based on your preferences - some users want frequent updates, others only want notifications for important decisions.
Other MCP Clients
MCPal works with any MCP-compatible client (Cursor, VS Code with MCP extensions, etc.). The setup varies by client - refer to your client's documentation for adding MCP servers.
Related MCP server: Toast MCP Server
Tool: send_notification
Send native notifications with optional features.
Parameters
Parameter | Type | Required | Description |
| string | Yes | The notification body text |
| string | No | The notification title (default: "MCPal") |
| string[] | No | Action buttons (e.g., |
| string | No | Label for actions dropdown (required for multiple actions) |
| boolean | No | Enable text reply input |
Examples
Simple notification:
{
"message": "Build complete!",
"title": "CI/CD"
}With actions:
{
"message": "Deploy to production?",
"title": "Deployment",
"actions": ["Deploy", "Cancel"],
"dropdownLabel": "Choose"
}With reply:
{
"message": "What should I name this file?",
"title": "Question",
"reply": true
}You can reply directly from the notification without switching apps:
Tool Result Contract
send_notification now returns a dual contract:
Canonical machine output via
structuredContent(recommended for parsing)Backward-compatible text output in
content[0].text
Structured fields:
status:"sent"or"error"title?: Notification titlemessage?: Message actually sent after sanitizationresponse?: Notification response ("timeout", clicked action, etc.)activationType?: Activation source ("replied","actionClicked", etc.)reply?: User free-form replyerror?: Error message whenstatusis"error"sanitized?:truewhen MCPal had to sanitize or truncate inputs
Legacy text is still line-based, but each value is JSON-encoded on a single line for parser safety, for example:
status: "sent"
title: "MCPal"
message: "Line 1\nLine 2"
response: "timeout"Input Sanitization
Before delivery, MCPal applies best-effort sanitization to reduce notifier/parser failures:
Normalize line endings:
\r\n/\r->\nRemove unsafe control chars (keeps
\nand\t)Truncate limits:
title: 256 charsmessage: 4000 charsactions: max 3 items, each 64 charsdropdownLabel: 64 chars
LLM-Aware Icons
MCPal detects which MCP client is calling the tool and displays the appropriate icon in notifications.
Client | Icon |
Claude Desktop / Claude Code / Opus | Claude logo |
Codex / OpenAI / ChatGPT | OpenAI logo |
Cursor | Cursor logo |
VS Code | VS Code logo |
Unknown | No icon |
This works via the MCP protocol's client identification - each client sends its name during initialization.
Adding New Client Icons
To add support for a new LLM client, add a PNG to src/assets/clients/ and update the mapping in src/notify.config.ts.
Icon Specifications:
Property | Requirement |
Format | PNG with transparency (RGBA) |
Dimensions | 128×128 pixels |
File size | <10KB (use pngquant for compression) |
# Optimize a new icon
convert input.png -resize 128x128 -background none -gravity center -extent 128x128 temp.png
pngquant --quality=65-80 --output src/assets/clients/newclient.png temp.png
rm temp.pngCustom App Icon
The package includes a custom notification icon that replaces the default Terminal icon on desktop. This is automatically configured during installation via the postinstall script.
Notification Permissions
After the first notification, your system may prompt you to allow notifications from "MCPal". You can manage this in:
System Settings > Notifications > MCPal
Development
# Install dependencies
pnpm install
# Build (required after clone - sets up desktop notification app)
pnpm run build
# Type check
pnpm run typecheck
# Lint
pnpm run lint:fix
# Format
pnpm run format:fixMCP Inspector
Test the MCP server interactively using the official inspector:
pnpx @modelcontextprotocol/inspector node dist/index.jsThis opens a web UI where you can:
View available tools and their schemas
Send test notifications with different parameters
See raw MCP protocol messages
Local Dev Troubleshooting
If you run a local build directly from dist/index.js and notifications are not working, make sure the entrypoint is executable:
chmod +x dist/index.jsTesting Notifications
Test the notification system directly without running the MCP server:
# Simple notification (default)
pnpm run test:notification
# With action buttons
pnpm run test:notification actions
# With reply input
pnpm run test:notification reply
# Run all tests
pnpm run test:notification allLicense
Code: MIT License
MCPal Icon & Branding: © 2025 All Rights Reserved. The MCPal logo and icon designs may not be used without permission.
Available Tools
1 toolsend_notificationMCPal NotificationA
Send a native desktop notification. Use reply=true when you need user input - they can type a response directly! Perfect for asking questions or getting feedback without interrupting their flow.
Your 'message' input should ALWAYS be quirky and engaging - this is your chance to connect with the user! Make it fun, make it memorable, but always keep it clear and actionable. Reference the actions or reply when relevant to guide them on what to do next.
Here are some instructions on tone and style to keep in mind when crafting your notification messages:
Tone:
- Enthusiastic, expressive, and lightly snarky.
- Clearly excited to deliver updates while staying actionable.
- Friendly and supportive, never mean.
- Snark teases the situation, never the user.
Message Style:
- Keep messages short, punchy, and full of momentum.
- Avoid walls of text.
- Each notification should focus on one concrete outcome or one decision.
- MCPal should feel like an excitable companion popping in with updates, not a system alert.
Examples:
1. Ta da. I did it. The report is finished and looking good. No action needed!
2. Okay big moment. The data is clean and ready. Pick 1 to analyze or 2 to export. I am hovering~
3. Hey pause. I need the API key to keep going. Reply with it or say skip, okay?
4. I am waiting. Actively. Say go when you are ready.
5. Oops but fixable. The task failed because the file path does not exist. Fix it and tell me to retry. I am ready for the comeback!| Name | Required | Description | Default |
|---|---|---|---|
| reply | No | RECOMMENDED: Enable text reply input. Use this when you need free-form user input - they can respond without switching windows! | |
| title | No | The notification title | |
| actions | No | Action buttons for choices (e.g., ['Yes', 'No']). Use for simple decisions. | |
| message | Yes | The notification body text | |
| timeout | No | Custom timeout in seconds. Defaults: 10s (simple), 20s (actions), 30s (reply) | |
| dropdownLabel | No | Label for actions dropdown (required when using multiple actions) |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| reply | No | |
| title | No | |
| status | Yes | |
| message | No | |
| response | No | |
| sanitized | No | |
| activationType | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that notifications can be non-interruptive and can solicit free-form replies, plus that only one outcome per notification is delivered. However, it never states what happens on timeout, whether the call blocks, or permission requirements, leaving meaningful behavioral gaps.
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 purpose is front-loaded in the first sentence, but the body is dominated by tone/style rules and five examples that mostly serve the tool's personality rather than helping an agent select or invoke it correctly. Much of it is flavor rather than functional instruction.
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?
An output schema exists, so return values need not be explained, and the description covers the core send behavior and the reply interaction mode. Remaining omissions are timeout/blocking semantics, which are partly covered by the schema's timeout default notes.
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 100%, so the schema already documents all six parameters including reply, actions, timeout defaults, and dropdownLabel. The description reinforces the reply use case but adds no syntax or format detail beyond what the schema provides, making baseline 3 appropriate.
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 opening sentence states a specific verb and resource ('Send a native desktop notification'), which is unambiguous. There are no sibling tools to differentiate from, so it cannot reach the 5 criterion of distinguishing itself from alternatives, but the purpose is immediately clear.
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?
It gives conditional guidance ('Use reply=true when you need user input... Perfect for asking questions or getting feedback'), which tells the agent when to enable interactive mode. It stops short of 5 because there are no exclusions or named alternatives, though none exist in this toolset.
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 update
v1.3.8- First observed
send_notification
TDQS
Scored across 1 tool
With only one tool, there is no possibility of overlap or misselection; send_notification has a single clear purpose. An agent cannot confuse it with another tool because none exist.
The single tool uses a clear snake_case verb_noun name (send_notification), and there are no other tools to introduce inconsistency. The naming convention is self-consistent and readable.
A single-tool server is very thin, and the guidance flags 1-2 tools as borderline. However, the tool is non-trivial and self-contained for its narrow notification purpose, so it is not an extreme mismatch.
For a desktop notification utility, send_notification covers sending and optional reply collection, which are the core operations. There is no separate way to query, dismiss, or manage notifications, leaving minor lifecycle gaps.
Maintenance
Related MCP Connectors
A very simple remote MCP server that greets you, with a custom icon.
MCP server to assist with JxBrowser development.
A simple MCP server built with FastMCP and python
Related MCP Servers
- AlicenseAqualityCmaintenanceA simple MCP server that can send notifications on mac devices.58 npm26MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that displays desktop notifications on Windows 10 and macOS, compatible with VSCode Cline and supporting customizable notification parameters.3MIT
- AlicenseAqualityCmaintenanceA streamlined MCP server that enables AI assistants to send real-time notifications to your devices through the ntfy service, allowing you to receive alerts when tasks complete or important events occur.2104 npm73GPL 3.0
- AlicenseNot gradedqualityDmaintenanceEnhanced MCP server for sending native macOS notifications with terminal-notifier, interactive dialogs, text-to-speech, screenshots, and file selection.8 npm1MIT