How do I use mcp-windows-notify?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-windows-notify Send a notification that the backup is done." 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.

mcp-windows-notify

by timtoday

Overview Schema Related Servers Score Discussions

Local

Windows通知MCP插件

NPM Version GitHub License

一个专为Windows环境设计的MCP（Model Context Protocol）插件，支持在AI开发工具最小化时通过系统通知提醒用户任务完成状态。

快速开始

直接在您的MCP配置中使用，无需预先安装：

{
  "mcpServers": {
    "windows-notify": {
      "command": "npx",
      "args": ["-y", "mcp-windows-notify"]
    }
  }
}

Related MCP server: Notifications MCP Server

功能特性

🔔 Windows原生系统通知支持
🎨 多种通知图标类型（信息、警告、错误、成功）
🔊 可配置声音提醒
⏰ 自定义通知显示时长
🛠️ 多种预设通知类型（任务完成、错误提醒、一般提醒）
⚙️ 环境变量配置支持

安装方法

方法一：NPX（推荐）

无需预先安装，直接在MCP配置中使用：

npx mcp-windows-notify

方法二：全局安装

npm install -g mcp-windows-notify

方法三：从源码安装

git clone https://github.com/timtoday/mcp-windows-notify.git
cd mcp-windows-notify
npm install
npm run build
npm install -g .

配置

复制 .env.example 为 .env 并根据需要修改配置：

# Windows通知配置
NOTIFICATION_TITLE=AI助手通知
NOTIFICATION_SOUND=true
NOTIFICATION_TIMEOUT=5000
NOTIFICATION_ICON=info

# MCP服务器配置
MCP_SERVER_NAME=windows-notify
MCP_SERVER_VERSION=1.0.0

使用方法

在AI开发工具中配置

在你的AI开发工具（如Claude Desktop、Cursor等）的MCP配置中添加：

使用npx（推荐）

{
  "mcpServers": {
    "windows-notify": {
      "command": "npx",
      "args": ["-y", "mcp-windows-notify"],
      "env": {
        "NOTIFICATION_TITLE": "AI助手通知",
        "NOTIFICATION_SOUND": "true",
        "NOTIFICATION_TIMEOUT": "5000",
        "NOTIFICATION_ICON": "info"
      }
    }
  }
}

使用本地安装版本

{
  "mcpServers": {
    "windows-notify": {
      "command": "mcp-windows-notify",
      "env": {
        "NOTIFICATION_TITLE": "AI助手通知",
        "NOTIFICATION_SOUND": "true",
        "NOTIFICATION_TIMEOUT": "5000",
        "NOTIFICATION_ICON": "info"
      }
    }
  }
}

可用工具

1. send_notification

发送自定义Windows系统通知

参数：

message (必需): 通知消息内容
title (可选): 通知标题
icon (可选): 图标类型 (info, warning, error, success)
sound (可选): 是否播放声音
timeout (可选): 显示时长（毫秒）
subtitle (可选): 副标题

2. notify_task_complete

发送任务完成通知

参数：

taskName (必需): 任务名称
details (可选): 任务详情

3. notify_error

发送错误通知

参数：

errorMessage (必需): 错误消息
details (可选): 错误详情

4. notify_reminder

发送提醒通知

参数：

message (必需): 提醒消息
subtitle (可选): 副标题

使用示例

当AI助手完成代码修改后，可以调用：

// 任务完成通知
notify_task_complete({
  "taskName": "代码重构完成",
  "details": "已成功重构用户认证模块，请继续开发"
})

// 错误通知
notify_error({
  "errorMessage": "编译失败",
  "details": "发现3个TypeScript类型错误"
})

// 自定义通知
send_notification({
  "title": "开发提醒",
  "message": "请检查新增的API接口文档",
  "icon": "info",
  "sound": true
})

技术栈

Node.js - 运行环境
TypeScript - 开发语言
@modelcontextprotocol/sdk - MCP协议支持
node-notifier - Windows通知API

系统要求

Windows 10/11
Node.js 18.0.0+
PowerShell 5.0+

贡献

欢迎贡献代码！请查看 CONTRIBUTING.md 了解详细信息。

开发

git clone https://github.com/timtoday/mcp-windows-notify.git
cd mcp-windows-notify
npm install
npm run dev  # 监听文件变化并自动编译

提交问题

如果您遇到问题或有功能建议，请在 GitHub Issues 中提交。

支持

📖 文档
🐛 问题反馈
💬 讨论

许可证

MIT License - 查看 LICENSE 文件了解详细信息。

Available Tools

7 tools

notify_ai_work_completeC

发送AI工作完成通知（特别醒目）

ParametersJSON Schema

Name	Required	Description	Default
`workType`	Yes	AI完成的工作类型（如：代码生成、文档编写等）
`details`	No	工作详情（可选）

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are present, so the description must disclose behavior. It mentions 'particularly eye-catching' but does not clarify what that entails (e.g., popup, sound, persistence) or any side effects. No contradiction with annotations.

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 description is a single sentence, which is concise but lacks structure and depth. It is minimally adequate but could be more informative.

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 multiple sibling notification tools, the description fails to explain what uniquely identifies AI work completion or why the eye-catching aspect matters. No output schema or return value info is provided.

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 coverage is 100%, with both parameters described. The description adds no new meaning beyond the schema, so baseline 3 is appropriate.

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 clearly states it sends an AI work completion notification with an emphasis on being eye-catching. However, it does not differentiate this tool from siblings like notify_task_complete or send_urgent_notification.

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 on when to use this tool versus the six sibling notification tools. There is no mention of prerequisites, context, or alternatives.

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

notify_dev_tool_statusC

发送开发工具状态通知

ParametersJSON Schema

Name	Required	Description	Default
`status`	Yes	状态类型
`message`	Yes	状态消息

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 the full burden. It only states the action without disclosing behavioral traits such as side effects, delivery guarantees, or required permissions. The agent learns nothing beyond the basic purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with purpose. No extraneous words. However, it may be too minimal for a tool with moderate complexity and siblings.

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

Completeness3/5

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

Given the tool has only 2 required parameters, an enum, no nested objects, and no output schema, the description is adequate but leaves gaps in usage context and behavior. It is minimally complete.

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 coverage is 100%, so the baseline is 3. The description adds no additional semantics for the parameters beyond what the schema already provides (e.g., status and message types).

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 indicates the tool sends notifications about development tool status. It is specific about the resource ('dev tool status') and action ('send notification'), but does not explicitly differentiate from sibling tools like notify_error or send_notification, which could overlap.

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 guidelines are provided on when to use this tool versus the siblings (e.g., notify_error, notify_ai_work_complete). The description does not mention any context, exclusions, or alternative tools, leaving the agent without direction.

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

notify_errorC

发送错误通知

ParametersJSON Schema

Name	Required	Description	Default
`errorMessage`	Yes	错误消息
`details`	No	错误详情（可选）

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits but only states the action; no info on delivery guarantees, logging, or side effects.

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?

Extremely concise (single phrase), but lacks sentence structure and elaboration; minimalism here sacrifices informativeness.

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?

For a simple notification tool, the description omits post-send behavior, required permissions, and failure modes, leaving gaps for the agent.

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 coverage is 100% with descriptions for both params; the tool description adds no additional meaning beyond the schema.

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 states it sends error notifications, matching the tool name and clearly distinguishing from sibling tools that handle non-error notifications.

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 on when to use this tool versus siblings like send_notification or send_urgent_notification; context of use is absent.

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

notify_reminderC

发送提醒通知

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	提醒消息
`subtitle`	No	提醒副标题（可选）

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description should disclose behavioral traits. It only states the tool sends a reminder, but does not describe what happens when called (e.g., where the notification appears, whether it is persistent, or if any destructive actions occur). This is insufficient for an agent to understand the tool's behavior.

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 description is a single sentence, which is concise but lacks structure and depth. It is appropriately front-loaded but does not earn its place due to missing crucial information.

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 existence of multiple sibling notification tools, the description is incomplete. It does not explain how 'reminder' notifications differ from error or task completion notifications, nor does it describe the return value or side effects. With no output schema, 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 coverage is 100% (both parameters are described in the schema). The description adds no extra meaning beyond what's in the schema, so it meets the baseline of 3.

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 'Send reminder notification' (发送提醒通知), indicating the tool's function as a notification sender for reminders. While it distinguishes from siblings by specifying 'reminder', it does not explicitly differentiate from other notification tools like 'notify_error' or 'send_urgent_notification', leaving some ambiguity.

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 on when to use this tool versus alternatives. The description lacks any context about use cases, prerequisites, or situations where this tool is preferred over sibling notification tools.

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

notify_task_completeC

发送任务完成通知

ParametersJSON Schema

Name	Required	Description	Default
`taskName`	Yes	任务名称
`details`	No	任务详情（可选）

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description fails to disclose any behavioral traits such as side effects, authentication needs, or delivery mechanism. The minimal phrasing 'send notification' does not elaborate on what happens or what is required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. It is front-loaded with the action and target. However, it could be slightly more structured to include context, but for a simple tool it is acceptably concise.

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 too minimal. It does not explain who receives the notification, whether it is immediate, or any other contextual details that would help an agent assess the tool's effects.

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?

Both parameters have descriptions in the schema (taskName, details), achieving 100% coverage. The description adds no additional meaning beyond the schema, which already explains the parameters. Baseline 3 is 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 description clearly states the verb '发送' (send) and resource '任务完成通知' (task completion notification), making the basic purpose evident. However, it does not differentiate from sibling tools like notify_error or notify_reminder, which could cause confusion.

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 on when to use this tool versus alternatives. There is no mention of prerequisites, expected scenarios, or exclusions, leaving the agent to infer usage solely from the name.

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

send_notificationC

发送Windows系统通知

ParametersJSON Schema

Name	Required	Description
`message`	Yes	通知消息内容
`title`	No	通知标题（可选）
`icon`	No	通知图标类型（可选）
`sound`	No	是否播放声音（可选）
`timeout`	No	通知显示时长（毫秒，可选）
`subtitle`	No	通知副标题（可选）

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the notification is blocking, asynchronous, or what happens on failure. This is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a concise single sentence, but it could be expanded to include key details without being verbose. It front-loads the purpose well.

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?

With 6 parameters, no output schema, and no annotations, the description alone is insufficient for an agent to understand return values, error handling, or system requirements. It lacks completeness.

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 input schema already documents all parameters. The description adds no extra meaning beyond the schema, meeting the baseline for this dimension.

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 tool sends a Windows system notification, which is a specific verb-resource combination. However, it does not differentiate from siblings like send_urgent_notification or notify_task_complete, which have similar functionality.

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 on when to use this tool versus alternatives. For example, it does not specify that it should be used for general notifications or that send_urgent_notification is for critical messages.

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

send_urgent_notificationB

发送醒目的常驻通知（直到用户关闭）

ParametersJSON Schema

Name	Required	Description
`message`	Yes	通知消息内容
`title`	No	通知标题（可选）
`icon`	No	通知图标类型（可选）
`sound`	No	是否播放声音（可选）

TDQS

B3.4/5.0

Behavior3/5

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

The description discloses the persistent, prominent nature and that the user must close it. No annotations exist, so the description carries the burden. It does not mention permission requirements, response behavior, or effects on other notifications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no extraneous words. It front-loads the key behavior. Slightly more structure could improve readability, but it is efficient for its length.

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

Completeness3/5

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

Given the tool's simplicity and available sibling tools, the description provides adequate context for an agent to understand the core function. However, adding usage guidance and behavioral details would improve completeness.

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 baseline is 3. The description does not add extra information about the parameters beyond what is in the schema. No parameter-specific elaboration is provided.

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 it sends a prominent persistent notification that only closes when the user dismisses it. This distinguishes it from siblings like send_notification, which likely sends a non-persistent notification.

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 on when to use this tool versus alternatives like notify_ai_work_complete or notify_error. The description implies urgency but does not specify contexts or exclusions.

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.1/5.0

Disambiguation4/5

Most tools have distinct notification types (error, reminder, urgent), but 'notify_ai_work_complete' and 'notify_task_complete' have overlapping purposes that could cause confusion without careful inspection.

Naming Consistency3/5

Majority use the 'notify_' prefix, but two tools use 'send_' (send_notification, send_urgent_notification), breaking the pattern and making the set inconsistent.

Tool Count5/5

Seven tools cover a variety of notification scenarios without being excessive; the count is well-scoped for a notification-focused server.

Completeness4/5

The tool surface covers common notification use cases (error, reminder, task complete), but lacks a generic custom notification tool, which is a minor gap.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

AgentPing
io.github.Noriget
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Communication Email
2
kweenkl-mcp A
io.github.antoinedelorme
Push notifications for AI agents - send instant iPhone notifications from any MCP client.
Communication App Automation
62
Tycana
io.github.tycana
Gives your AI assistant persistent memory and intelligence about your work patterns.
Knowledge & Memory Autonomous Agents Developer Tools
2
Reflecto AOAuth
dev.reflecto
Reach your own phone from an AI agent: notifications, approval questions, reminders, ring, files.
Autonomous Agents Communication Workplace & Productivity
92

Related MCP Servers

AI Notify MCP
Developer Tools App Automation
zhiyingzzhou
F
license
C
quality
D
maintenance
Sends system notifications when AI completes responses in MCP-compatible code editors, with cross-platform support for macOS, Windows, and Linux including customizable titles, messages, icons, and sound effects.
Updated a year ago (2025-07-01 08:12 UTC)
2
Notifications MCP Server
OS Automation App Automation
ohqay
A
license
Not graded
quality
D
maintenance
Enables AI assistants to send native macOS notifications for task completion alerts and reminders. Supports interactive features like custom system sounds, action buttons, and user replies directly from the notification center.
Updated a year ago (2025-06-19 02:30 UTC)
201
MIT
mcp-win-toast
OS Automation Developer Tools
ShigeruWakida
A
license
B
quality
D
maintenance
Enables AI assistants to send Windows toast notifications and dialog boxes, allowing them to actively notify users and request confirmations through native Windows UI.
Updated 6 months ago (2026-02-28 15:07 UTC)
2
1
ISC
Desktop Notification MCP
Communication OS Automation Developer Tools
GhostTypes
F
license
Not graded
quality
D
maintenance
Enables AI agents to send cross-platform desktop notifications with priority levels, categories, and configurable duration.
Updated 10 months ago (2025-11-14 02:39 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/timtoday/mcp-windows-notify'

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