Skip to main content
Glama

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@latest

Claude 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@latest

Configuring 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

message

string

Yes

The notification body text

title

string

No

The notification title (default: "MCPal")

actions

string[]

No

Action buttons (e.g., ["Yes", "No", "Maybe"])

dropdownLabel

string

No

Label for actions dropdown (required for multiple actions)

reply

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 title

  • message?: Message actually sent after sanitization

  • response?: Notification response ("timeout", clicked action, etc.)

  • activationType?: Activation source ("replied", "actionClicked", etc.)

  • reply?: User free-form reply

  • error?: Error message when status is "error"

  • sanitized?: true when 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 -> \n

  • Remove unsafe control chars (keeps \n and \t)

  • Truncate limits:

    • title: 256 chars

    • message: 4000 chars

    • actions: max 3 items, each 64 chars

    • dropdownLabel: 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.png

Custom 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:fix

MCP Inspector

Test the MCP server interactively using the official inspector:

pnpx @modelcontextprotocol/inspector node dist/index.js

This 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.js

Testing 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 all

License

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 tool
send_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!
ParametersJSON Schema
NameRequiredDescriptionDefault
replyNoRECOMMENDED: Enable text reply input. Use this when you need free-form user input - they can respond without switching windows!
titleNoThe notification title
actionsNoAction buttons for choices (e.g., ['Yes', 'No']). Use for simple decisions.
messageYesThe notification body text
timeoutNoCustom timeout in seconds. Defaults: 10s (simple), 20s (actions), 30s (reply)
dropdownLabelNoLabel for actions dropdown (required when using multiple actions)

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNo
replyNo
titleNo
statusYes
messageNo
responseNo
sanitizedNo
activationTypeNo

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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. 1 tool updatev1.3.8
    • First observedsend_notification

TDQS

A3.8/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers