Skip to main content
Glama
yuki-yano

macOS Notify MCP

by yuki-yano
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

macOS Notify MCP

A Model Context Protocol (MCP) server for macOS notifications with tmux integration. This tool allows AI assistants like Claude to send native macOS notifications that can focus specific tmux sessions when clicked.

Features

  • 🔔 Native macOS notifications using UserNotifications API

  • 🖱️ Clickable notifications that focus tmux sessions

  • 🎯 Direct navigation to specific tmux session, window, and pane

  • 🔊 Customizable notification sounds

  • 🚀 Support for multiple concurrent notifications

  • 🤖 MCP server for AI assistant integration

  • 🖥️ Terminal emulator detection (VSCode, Cursor, iTerm2, Terminal.app)

Related MCP server: mcp-macos-utils

Installation

Prerequisites

  • macOS (required for notifications)

  • Node.js >= 18.0.0

  • tmux (optional, for tmux integration)

Install from npm

npm install -g macos-notify-mcp

Build from source

git clone https://github.com/yuki-yano/macos-notify-mcp.git
cd macos-notify-mcp
npm install
npm run build
npm run build-app  # Build the macOS app bundle (only needed for development)

Usage

As MCP Server

First, install the package globally:

npm install -g macos-notify-mcp

Quick Setup with Claude Code

Use the claude mcp add command:

claude mcp add macos-notify -s user -- macos-notify-mcp

Then restart Claude Code.

Manual Setup for Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "macos-notify": {
      "command": "macos-notify-mcp"
    }
  }
}

Available MCP Tools

  • send_notification - Send a macOS notification

    • message (required): Notification message

    • title: Notification title (default: "Claude Code")

    • sound: Notification sound (default: "Glass")

    • session: tmux session name

    • window: tmux window number

    • pane: tmux pane number

    • useCurrent: Use current tmux location

  • list_tmux_sessions - List available tmux sessions

  • get_current_tmux_info - Get current tmux session information

As CLI Tool

# Basic notification
macos-notify-cli -m "Build completed"

# With title
macos-notify-cli -t "Development" -m "Tests passed"

# With tmux integration
macos-notify-cli -m "Task finished" -s my-session -w 1 -p 0

# Use current tmux location
macos-notify-cli -m "Check this pane" --current-tmux

# Detect current terminal emulator
macos-notify-cli --detect-terminal

# List tmux sessions
macos-notify-cli --list-sessions

Terminal Detection

The tool automatically detects which terminal emulator you're using and uses this information when you click on notifications to focus the correct application. You can test terminal detection with:

# Test terminal detection
macos-notify-cli --detect-terminal

Supported Terminal Detection

The tool detects terminals using various methods:

  1. Cursor: Via CURSOR_TRACE_ID environment variable

  2. VSCode: Via VSCODE_IPC_HOOK_CLI or VSCODE_REMOTE environment variables

  3. alacritty: Via ALACRITTY_WINDOW_ID or ALACRITTY_SOCKET environment variables

  4. iTerm2: Via TERM_PROGRAM=iTerm.app

  5. Terminal.app: Via TERM_PROGRAM=Apple_Terminal

Terminal Detection in tmux

When running inside tmux, the tool attempts to detect which terminal emulator the active tmux client is using:

  1. Active Client Detection: Identifies the most recently active tmux client

  2. TTY Process Analysis: Traces processes using the client's TTY

  3. Environment Preservation: Checks preserved environment variables

  4. Process Tree Fallback: Analyzes the process tree as a last resort

For advanced tmux client tracking, see examples/tmux-client-tracking.sh.

How it Works

  1. Notification Delivery: Uses a native macOS app bundle (MacOSNotifyMCP.app) to send UserNotifications API notifications

  2. Click Handling: When a notification is clicked, the app activates the detected terminal emulator (VSCode, Cursor, iTerm2, alacritty, or Terminal.app) and switches to the specified tmux session

  3. Terminal Support: Automatically detects and activates the correct terminal application

  4. Multiple Instances: Each notification runs as a separate process, allowing multiple concurrent notifications

Architecture

The project consists of two main components:

  1. MCP Server/CLI (TypeScript/Node.js)

    • Implements the Model Context Protocol

    • Provides a command-line interface

    • Manages tmux session detection and validation

  2. MacOSNotifyMCP.app (Swift/macOS)

    • Native macOS application for notifications

    • Handles notification clicks to focus tmux sessions

    • Runs as a background process for each notification

MacOSNotifyMCP.app

The MacOSNotifyMCP.app is bundled with the npm package and is automatically available after installation. No additional setup is required.

Troubleshooting

Notifications not appearing

  1. Check System Settings → Notifications → MacOSNotifyMCP

  2. Ensure notifications are allowed

  3. Run macos-notify-mcp -m "test" to verify

tmux integration not working

  1. Ensure tmux is installed and running

  2. Check session names with macos-notify-mcp --list-sessions

  3. Verify terminal app is supported (Alacritty, iTerm2, WezTerm, or Terminal)

Development

# Install dependencies
npm install

# Build TypeScript
npm run build

# Run in development
npm run dev

# Lint and format code
npm run lint
npm run format

# Build macOS app (only if modifying Swift code)
npm run build-app

License

MIT

Author

Yuki Yano

Available Tools

3 tools
get_current_tmux_infoC

Get current tmux session information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe any behavioral traits - no information about what 'current' means operationally, whether this requires specific tmux environment, what format the information returns, or any error conditions. The description is minimal and lacks behavioral context.

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 extremely concise at just 5 words - 'Get current tmux session information'. It's front-loaded with the core purpose and contains no unnecessary words or sentences. Every word earns its place in conveying the basic function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no annotations, no output schema, and a sibling tool with similar purpose ('list_tmux_sessions'), the description is insufficiently complete. It doesn't explain what 'current' means versus 'list', what information is returned, or how this tool differs from its sibling. For a tool that presumably returns data, the lack of output description is a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist. This meets the baseline expectation for parameterless tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get current tmux session information' clearly states the verb ('Get') and resource ('current tmux session information'), making the purpose understandable. However, it doesn't distinguish this from the sibling tool 'list_tmux_sessions' - both appear to retrieve tmux session data, so the distinction between 'current' and 'list' isn't clarified.

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

Usage Guidelines2/5

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

No guidance is provided about when to use this tool versus the sibling 'list_tmux_sessions'. The description implies it retrieves 'current' information, but doesn't specify what 'current' means in this context or when you would choose this over listing all sessions. No alternatives or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tmux_sessionsB

List available tmux sessions

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves—no information on output format, error conditions, permissions needed, or whether it's read-only/destructive. This is inadequate for a tool with zero annotation coverage.

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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., session names, IDs, status) or any behavioral context, which is essential for an agent to use it effectively. The simplicity of 0 parameters doesn't compensate for these gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it correctly doesn't mention any, earning a baseline score of 4 for appropriate compensation.

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 description clearly states the verb ('List') and resource ('available tmux sessions'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_current_tmux_info' which might overlap in functionality, preventing a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'get_current_tmux_info' or 'send_notification'. There's no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_notificationC

Send a macOS notification with optional tmux integration

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesThe notification message
titleNoThe notification title (default: "Claude Code")
soundNoThe notification sound (default: "Glass")
sessionNotmux session name
windowNotmux window number
paneNotmux pane number
useCurrentNoUse current tmux location

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool sends notifications and has tmux integration, but doesn't describe what happens when notifications are sent (do they appear immediately? require permissions?), what errors might occur, or any rate limits. The description is minimal and leaves important behavioral aspects unspecified.

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 extremely concise - a single sentence that efficiently communicates the core functionality and key feature. Every word earns its place with no wasted text, making it front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a notification tool with 7 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, what happens on success/failure, platform requirements (macOS only?), or how the tmux integration actually works. For a tool with this complexity, more context is needed.

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 7 parameters thoroughly with descriptions and defaults. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter documentation.

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 description clearly states the action ('send') and resource ('macOS notification'), and mentions the optional tmux integration feature. However, it doesn't specifically differentiate this tool from its siblings (get_current_tmux_info, list_tmux_sessions), which are query tools while this is a notification tool.

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

Usage Guidelines2/5

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

The description mentions 'optional tmux integration' which implies some context for when tmux parameters might be relevant, but provides no explicit guidance about when to use this tool versus alternatives, when not to use it, or what prerequisites might be needed for macOS notifications or tmux integration to work.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: get_current_tmux_info retrieves details about the current session, list_tmux_sessions enumerates all available sessions, and send_notification handles macOS notifications with optional tmux integration. There is no overlap or ambiguity between these functions.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern (get_current_tmux_info, list_tmux_sessions, send_notification) with clear actions and objects. The minor deviation is that send_notification uses a more generic object term compared to the tmux-specific others, but it remains readable and coherent.

Tool Count3/5

With only 3 tools, the set feels thin for a server named 'macOS Notify MCP', which suggests broader macOS notification capabilities. While the tools cover tmux session management and notifications, the scope might be too narrow, potentially lacking other notification-related operations.

Completeness3/5

The tools provide basic tmux session info and notification sending, but there are notable gaps. For a macOS notification server, expected features like managing notification settings, handling different notification types, or integrating with other system events are missing, limiting the surface's completeness.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • mcp-macos-utils

    msageryd
    F
    license
    A
    quality
    D
    maintenance
    An MCP server that enables AI assistants to send native macOS notifications with automatic project detection and categorization. It includes logging capabilities for all notifications to provide an audit trail of system alerts.
    1

  • mcp-tmux

    laszlopere
    A
    license
    B
    quality
    B
    maintenance
    A comprehensive MCP server for driving tmux sessions, windows, panes, sending keystrokes, and reading pane output locally or over SSH, enabling real-time collaborative pairing with AI.
    71
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yuki-yano/macos-notify-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server