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., "@notification-mcp Send a push notification saying 'Hello from MCP'."
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.
这是一个使用 FastMCP 框架构建的消息推送服务集合。它支持 Bark 和 PushDeer。
这个包提供了两个主要命令：mcp-bark 和 mcp-pushdeer。你可以使用像 uvx 或 pipx 这样的工具来运行它们。
使用 uvx 的例子：
# 运行 Bark 服务
# 这将启动 Bark 通知的 MCP 服务器
uvx --from notification_mcp mcp-bark
# 运行 PushDeer 服务
# 这将启动 PushDeer 通知的 MCP 服务器
uvx --from notification_mcp mcp-pushdeer一旦服务启动，你就可以使用 FastMCP 客户端或其他兼容方法来与工具（如 send_message）进行交互。
Related MCP server: Jon's Pushover MCP Server
在运行命令之前，请配置以下环境变量：
对于 Bark (mcp-bark）：
BARK_DEVICE_KEYS: 必需。逗号分隔的 Bark 设备密钥列表（例如 key1,key2）。
BARK_SERVER: 可选。自建 Bark 服务器 URL，默认为 https://api.day.app。
对于 PushDeer (mcp-pushdeer）：
PUSHDEER_KEYS: 必需。逗号分隔的 PushDeer 密钥列表（例如 keyA,keyB）。
PUSHDEER_SERVER: 可选。自建 PushDeer 服务器 URL，默认为 https://api2.pushdeer.com。
mcp-bark)提供以下工具：
send_message(title: str, content: str) -> str: 向所有配置的 Bark 设备发送带有指定标题和内容的通知。
mcp-pushdeer)提供以下工具：
send_message(text: str, desp: Optional[str] = None, type: str = 'text', pushkey: Optional[str] = None) -> str: 发送消息。type 可以是 'text'、'markdown' 或 'image'（其中 text 是图像 URL）。
send_markdown(markdown: str, desp: Optional[str] = None, pushkey: Optional[str] = None) -> str: 一个发送 Markdown 消息的便捷工具。
send_image(image_url: str, desp: Optional[str] = None, pushkey: Optional[str] = None) -> str: 一个通过 URL 发送图像消息的便捷工具。
MIT
向所有配置的 Bark 设备发送消息
Args:
title: 消息标题
content: 消息内容
Returns:
str: 发送结果
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states it sends to all configured devices but omits details like whether it's non-blocking, error handling, or what the return string signifies.
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 description is extremely concise with one sentence for purpose and a brief formatted list for args and returns. No redundant text.
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?
Given the absence of annotations and output schema, the description is too minimal. It lacks information on return values, potential errors, and how the tool behaves in edge cases.
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 coverage is 0%, so the description must add meaning. It lists 'title' and 'content' but provides no additional constraints, formats, or examples beyond the parameter names.
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 description clearly states the tool sends messages to all configured Bark devices, specifying the action and target. The verb 'send' and resource 'Bark devices' are precise.
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?
No guidance on when to use this tool versus alternatives, and no context about prerequisites or typical scenarios. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.3send_messageScored across 1 tool
With only one tool, there is no risk of ambiguity between tools. The single tool has a clear purpose.
Only one tool exists, so naming consistency is trivially maintained. The tool name 'send_message' is clear and follows common conventions.
A single tool for a notification server is too few. Even for a minimal server, one would expect at least a few tools for device management or status checks.
The tool surface is very incomplete. There is no way to configure devices, retrieve sending status, or handle errors. The server only supports sending messages without any supporting operations.
Push notifications for AI agents - send instant iPhone notifications from any MCP client.
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Send, search, and manage notifications, accounts, and push preferences
Push notifications with personalized sounds - manage and trigger your vybits via MCP
