Skip to main content
Glama
TG-Techie

push-notification-mcp

by TG-Techie
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

push-notification-mcp

A local MCP server that sends push notifications on macOS.

Quick Start

pnpm install && pnpm run build && npx @anthropic-ai/mcpb pack .

Drag the .mcpb into Claude Desktop or any MCPB-compatible client of your choice.

Related MCP server: MCP Notifications Server

Specification

NOTE: This project was generated from an NLSpec (included) and was wholly implemented (or "dark-complied") by a Claude model (code formatting not included) as an experiment/initial evaluation of the NLSpec approach (see below). Also

An NLSpec (as la the @TG-Techie flavor) is a prescriptive, generative specification written in natural language — precise enough to derive a faithful implementation from, flexible enough to leave genuine implementation choices to the builder. For background on the approach, see the strongdm/attractor repo where the concept was developed in practice.

How It Works

The server exposes a single MCP tool — send_notification — over stdio. When called, it delivers a native macOS notification displaying a title and body. The notification mechanism is osascript with display notification, invoked via execFile (no shell). User input is passed as argv to the AppleScript on run argv handler — never interpolated into script text.

Installation

As an MCPB Bundle

Build and pack:

pnpm install && pnpm run build && npx @anthropic-ai/mcpb pack .

This produces a .mcpb file you can install in Claude Desktop or any MCPB-compatible client.

As a Standalone MCP Server

Add to your MCP client configuration:

{
  "mcpServers": {
    "push-notification": {
      "command": "node",
      "args": ["/absolute/path/to/push-notification-mcp/dist/index.js"]
    }
  }
}

Or if published to npm:

{
  "mcpServers": {
    "push-notification": {
      "command": "npx",
      "args": ["-y", "push-notification-mcp"]
    }
  }
}

Run Directly

npm install
npm run build
node dist/index.js

The server communicates over stdio (stdin/stdout). Diagnostic logs go to stderr.

Environment Variables

All configuration is optional. The server works out of the box with sensible defaults.

Variable

Type

Default

Description

PUSH_NOTIFICATION_RATE_LIMIT_ENABLED

boolean

true

Set to false or 0 to disable rate limiting

PUSH_NOTIFICATION_RATE_LIMIT_BURST

integer

5

Token bucket capacity (max burst)

PUSH_NOTIFICATION_RATE_LIMIT_REFILL_MS

integer

12000

Milliseconds between token refills

Boolean values accept true/1 (truthy) and false/0 (falsy), case-insensitive. Integer values must be positive; invalid values are ignored and defaults are used, with a warning logged to stderr.

With defaults: burst of 5 notifications, then sustained rate of ~5 per minute (one every 12 s). The bucket refills continuously — idle for 60 s and it's full again.

Platform

macOS only. The notification delivery mechanism (osascript display notification) is available on all default macOS installations. macOS may prompt you to allow notifications from "Script Editor" — this is expected.

License

MIT

Available Tools

1 tool
send_notificationSend NotificationA

Send a push notification to the user. Use this to alert the user when a long-running task completes, when input is needed, or when something requires their attention.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyYesNotification body text. Describes what happened or what the user needs to know.
titleYesShort notification title. Typically identifies the context: branch name, workspace name, project name, or repository name.

TDQS

A4.2/5.0
Behavior3/5

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

Annotations are all false, so description carries full burden. It states 'send' but does not disclose potential side effects (e.g., rate limits, user opt-in, delivery guarantees). Basic behavior is clear but lacks depth.

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?

Two sentences, front-loaded with the action. Every sentence adds value with no wasted words.

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?

For a simple notification tool with no output schema and no siblings, the description covers purpose and usage well. Minor lack of detail on return behavior, but acceptable.

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 covers 100% with detailed descriptions for each parameter. The description reinforces overall context but does not add new parameter-level details beyond what the schema provides.

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 action ('Send a push notification') and provides specific use cases (long-running task completion, input needed, attention required), making the purpose highly distinct.

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

Usage Guidelines5/5

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

Explicit guidance is given on when to use: 'when a long-running task completes, when input is needed, or when something requires their attention.' No alternatives exist, so no exclusion needed.

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. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedsend_notification
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

With only a single tool, there is no possibility of confusion between tools. The tool's purpose is clearly unique and distinct by default.

Naming Consistency5/5

The single tool name 'send_notification' follows a clear verb_noun pattern. Naming consistency is not an issue with only one tool.

Tool Count3/5

A single tool for sending push notifications is on the low end. While it covers the core action, additional tools for registration or configuration would improve completeness, but the count is borderline acceptable.

Completeness3/5

The toolset covers the primary operation of sending a notification, but lacks any features for managing devices, subscriptions, or checking delivery status. This makes the surface incomplete for a full push notification service.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

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/TG-Techie/push-notif-mcp'

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