Click on "Install 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., "@mcp-notify Notify me when the build finishes"
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.
Ever started a long-running AI task and walked away, only to come back wondering if it finished? MCP Notify solves this by sending push notifications directly to your phone.
Stay Informed — Get notified when builds complete, tests pass, or tasks finish
Works Everywhere — Claude Desktop, Claude Code CLI, Cursor, Windsurf
Simple Setup — One command to install, QR code to pair
Privacy First — Notifications are encrypted and never stored longer than needed
Related MCP server: MCPing
1. Install the MCP server:
npx -y mcp-notification setup2. Download the iOS app:
3. Pair your device:
In your AI client, just say:
"Pair my phone"
Scan the QR code with the app. Done!
Run the setup wizard — it automatically detects and configures your AI clients:
npx -y mcp-notification setupThe wizard supports:
✅ Claude Desktop
✅ Claude Code CLI
✅ Cursor
✅ Windsurf
Add to ~/.claude/claude_desktop_config.json:
{
"mcpServers": {
"notify": {
"command": "npx",
"args": ["-y", "mcp-notification"]
}
}
}claude mcp add --transport stdio --scope user notify -- npx -y mcp-notificationAdd to .cursor/mcp.json or global config:
{
"mcpServers": {
"notify": {
"command": "npx",
"args": ["-y", "mcp-notification"]
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"notify": {
"command": "npx",
"args": ["-y", "mcp-notification"]
}
}
}After configuration, restart your AI client to load the MCP server.
Just talk naturally to your AI assistant:
"Notify me when you're done"
"Send a notification that the build completed"
"What's my notification quota?"
"List my paired devices"
"Remove my old phone"Long-running tasks:
"Run the full test suite and notify me when it's done"
Build monitoring:
"Build the project. If it succeeds, notify me with 'Build passed'. If it fails, send a high priority notification with the error."
Scheduled reminders:
"Send me a notification in 5 minutes to check the deployment"
Tool | Description | Parameters |
| Display QR code for pairing |
|
| Check if QR was scanned | — |
| Check if ready to send notifications | — |
| Send a push notification |
|
| View notification history |
|
| Check monthly usage limits | — |
| List all paired devices | — |
| Unpair a device |
|
Priority | Behavior |
| Silent delivery |
| Standard notification (default) |
| Prominent alert |
| Bypasses Do Not Disturb |
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ AI Client │ │ MCP Server │ │ iOS App │
│ (Claude, etc) │◀───────▶│ (mcp-notification)│◀───────▶│ (MCP Notify) │
└─────────────────┘ MCP └─────────────────┘ APNs └─────────────────┘
Protocol │
│
┌───────▼───────┐
│ Notify API │
│ (mcpnotify.dev)│
└───────────────┘Command Detection:
The package automatically detects how it's being invoked:
Invocation | Result |
| Setup wizard (always) |
| Setup wizard (TTY detected) |
Spawned by AI client | MCP stdio server (no TTY) |
| MCP server (always) |
This is achieved by checking process.stdin.isTTY — when you run it in a terminal, stdin is connected to a TTY. When an AI client spawns it, stdin is a pipe for MCP JSON-RPC communication.
Variable | Description | Default |
| Backend API URL |
|
Credentials are stored locally in ~/.mcp-notify/:
~/.mcp-notify/
├── credentials.json # API key and user info
└── pairing_state.json # Temporary pairing dataMake sure the client is installed and working
Check that config files exist and are writable
Try manual configuration instead
Check pairing status: say "check pairing status" to your AI
Verify the iOS app has notification permissions enabled
Check your quota: say "what's my quota"
The setup wizard detects existing configurations. To reconfigure:
Remove the existing entry from your client's config file
Run the setup wizard again
# Clone the repo
git clone https://github.com/box7e7/mcp-notify
cd mcp-notify
# Install dependencies
npm install
# Build
npm run build
# Test setup wizard locally
npm link
mcp-notification setup
# Run tests
npm test
# Development mode (watch)
npm run devmcp-notify/
├── src/
│ ├── index.ts # Entry point (TTY detection)
│ ├── cli/
│ │ ├── setup.ts # Setup wizard
│ │ ├── config-manager.ts # Client config management
│ │ └── platform-detector.ts
│ ├── tools/
│ │ ├── pairing.tools.ts # Device pairing
│ │ ├── notification.tools.ts
│ │ └── account.tools.ts
│ └── services/
│ ├── api-client.ts # Backend communication
│ ├── credentials.ts # Local credential storage
│ └── qr-generator.ts # QR code generation
├── package.json
└── tsconfig.jsonWebsite: https://mcpnotify.dev
iOS App: App Store
Support: support@mcpnotify.dev
MIT © box7e7
Check if the QR code has been scanned and pairing is complete. Use this after displaying a QR code.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It clearly conveys that this is a read-only status check rather than an action that initiates or completes pairing. It does not describe return values or polling behavior, but the core behavior is transparent.
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?
Two short sentences with no filler. The first sentence states the core purpose and the second provides immediate usage context, so the description is appropriately front-loaded and concise.
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?
For a zero-parameter, no-output-schema tool, the description is largely complete: it states the purpose and when to invoke it. It does not explicitly describe the result shape or distinguish it from get_setup_status, but the condition-checking language strongly implies a simple status result.
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?
The tool has zero parameters and the schema has full coverage, so there is no parameter documentation gap. The description adds meaning by clarifying what condition is being evaluated, which is useful context even with no params.
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 checks whether a QR code was scanned and whether pairing is complete, which is a specific verb and resource. It does not explicitly distinguish itself from sibling get_setup_status, but the QR-scan framing makes its role reasonably clear.
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?
The description explicitly says to use this after displaying a QR code, giving clear contextual guidance. It does not mention when not to use it or name alternatives, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View your recent notification history.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by tags | |
| limit | No | Number of notifications to return (default: 10, max: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry behavioral disclosure. It indicates a read-only operation via 'View', but does not disclose potential side effects (e.g., marking notifications read), ordering, limits, or authentication needs, leaving key behaviors unstated.
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?
A single short sentence with no filler. The verb-object structure is immediately front-loaded and easy to parse.
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?
The tool is simple with only two optional documented parameters, so the minimal description is mostly adequate. However, with no output schema and no annotations, it does not specify return format or what 'recent' means, leaving some gaps for an agent.
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 description coverage is 100%, so 'tags' and 'limit' are already documented structurally. The tool description adds no additional parameter context, matching the baseline score for high coverage.
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?
States a clear read operation ('View') with a specific resource ('your recent notification history'). This distinguishes it from sibling tools like send_notification (write) and list_devices (hardware), leaving no ambiguity about what it retrieves.
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 explicit when-to-use or alternative routing is provided. The only guidance is the description's implied use case: retrieving recent notification history, which is a reasonable inference but not spelled out compared with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your notification quota and usage. Shows how many notifications you can send this month.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does convey a read-only, non-mutating check and clarifies the month-bound quota scope. However, it does not disclose the exact response shape, whether it returns remaining, used, or total counts, or any auth/rate-limit caveats.
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?
Two short sentences deliver the core purpose and the concrete output with no filler. The action verb and resource appear immediately, making the description easy to scan and act on.
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?
For a zero-parameter, read-only quota checker, the description provides a clear mental model: monthly notification allowance and usage. It does not explain output formatting or exactly how 'usage' is counted, but those are minor gaps given the tool's simplicity and lack of required inputs.
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?
The tool has zero parameters, so the schema leaves nothing to interpret. The description still adds useful meaning by explaining that 'quota and usage' means the number of notifications sendable this month, which is sufficient for a no-input tool.
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 uses a specific verb ('Check') and clearly identifies the resource ('notification quota and usage'), then explains the concrete value it returns ('how many notifications you can send this month'). This distinguishes it naturally from siblings like send_notification and get_history.
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?
The description implies the tool should be used to check quota before sending notifications, but it does not explicitly state when to use it versus alternatives or mention any exclusions. No sibling tool is referenced for comparison, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if MCP Notify is set up and ready to send notifications. Returns pairing status and device count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. 'Check' and 'Returns pairing status and device count' indicate a read-only status operation without side effects, but the description does not explicitly state that it makes no changes or how readiness is determined.
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 two short sentences with no filler. It leads with the action and purpose, then briefly states the return contents. Every word contributes meaning.
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?
For a zero-parameter, low-complexity status check with no output schema, the description provides the essential information: what it checks and what it returns. Nothing critical is missing for an agent to invoke it correctly.
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?
The tool has zero parameters, so there is no parameter ambiguity. The baseline for zero-parameter tools is strong, and the description adds the relevant return context (pairing status and device count) that the empty schema cannot convey.
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 checks MCP Notify setup readiness and returns pairing status and device count. It is specific and unambiguous, though it does not explicitly differentiate itself from the sibling check_pairing_status beyond implying a broader readiness check.
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?
The phrase 'ready to send notifications' implies using this tool to verify setup before sending, but there is no explicit guidance about when to prefer it over check_pairing_status or list_devices. The usage context is inferable, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all paired devices that can receive notifications.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a good job: 'List' indicates a read-only operation, and the description discloses the key behavioral filter—returning only paired devices that can receive notifications. It does not describe return format or edge cases, but the core behavior is transparent.
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?
A single, front-loaded sentence conveys the action, the resource, and the key filtering criterion with no filler or redundant wording.
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?
For a zero-parameter list operation, the description provides enough scope for an agent to invoke it correctly. A note about the return representation or how results relate to sibling status tools would add context, but nothing essential for calling the tool is missing.
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?
The tool takes zero parameters and the schema is an empty object, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because there is no parameter ambiguity to resolve.
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 states a clear verb ('List'), resource ('all paired devices'), and a specific scoping condition ('that can receive notifications'). This clearly distinguishes it from sibling tools like pair_device, send_notification, or remove_device.
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 explicit guidance is given for when to use this tool versus check_pairing_status or get_setup_status. The intended use is implied by the name and description, but there are no exclusions, alternatives, or contextual cues to steer an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pair your phone to receive notifications. Displays a QR code to scan with the MCP Notify mobile app. This is the first step for new users.
| Name | Required | Description | Default |
|---|---|---|---|
| device_name | No | Optional friendly name for this pairing session |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It explains the interactive QR-code mechanism and positions the tool as onboarding, but it omits side effects such as replacing an existing pairing, session expiration, and what happens after the QR code is scanned.
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?
Three short, purposeful sentences with no filler. The core action and immediate QR-code behavior are front-loaded, and the first-step context is useful rather than redundant.
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?
For a low-complexity tool with one optional parameter and no output schema, the description gives a clear, largely complete picture of the tool's role and interactive flow. A minor gap is the lack of return-format or QR-expiry details, but the tool is simple enough that this is not a significant omission.
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 100%: device_name is already documented as an optional friendly name for the pairing session. The description adds no parameter detail, which is acceptable at the baseline because the schema fully covers it.
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?
Uses a specific verb 'Pair' with a clear resource ('your phone') and states the goal of receiving notifications. The QR-code flow and 'first step for new users' framing distinguish it from sibling management, status, and notification tools.
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?
Explicitly describes this as the first step for new users, giving an agent clear context about when to invoke it relative to setup and notification tools. It does not name exclusions or alternatives, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a paired device. It will no longer receive notifications.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | The ID of the device to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full behavioral burden. It does disclose a meaningful consequence ('It will no longer receive notifications'), indicating the tool affects the device's notification delivery. However, it does not mention reversibility, permissions, or whether the device record is fully deleted beyond notification removal.
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?
Two short sentences communicate the action and its key consequence with no filler. The essential information is front-loaded and every word earns its place.
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?
For a one-parameter mutation tool with no output schema, the description is minimally sufficient: it identifies the required input and the main effect. It lacks detail on errors, irreversibility, and return values, which would be useful for an agent handling failures or confirmation flows.
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 description coverage is 100%, and device_id is clearly documented as the ID of the device to remove. The description adds no parameter-level nuance, but the schema already handles parameter semantics fully, so the baseline of 3 applies.
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 uses a clear verb and resource ('Remove a paired device') and states the direct consequence. It is distinguishable from siblings like pair_device and list_devices by its destructive intent, though it does not explicitly name those alternatives.
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 is given on when to use this tool versus alternatives like pair_device or list_devices. There are no explicit context conditions, prerequisites, or exclusions; the intended use is only implied by the phrase 'paired device'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a push notification to your paired devices. Use this when the user asks to be notified about something.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to open when the notification is tapped | |
| body | No | Notification body text (max 1000 characters) | |
| tags | No | Tags for categorizing the notification | |
| title | Yes | Notification title (max 100 characters) | |
| priority | No | Notification priority. Use 'critical' sparingly as it bypasses Do Not Disturb. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly identifies the side effect of sending a push notification and scopes it to paired devices, but it does not mention what happens if no devices are paired, delivery guarantees, failure behavior, or other operational constraints.
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 two short sentences that both earn their place: one states the operation and target, the other gives the usage trigger. No redundant or filler content is present.
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?
The core purpose and parameter semantics are well covered, and the schema documents all parameters fully. However, with no output schema and no annotations, the agent is left without information about success/failure responses, prerequisites like having paired devices, or post-send behavior. This is acceptable for a simple send tool but not fully complete.
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 description coverage is 100%, so parameter semantics are already fully documented in the input schema. The description adds no additional parameter-level meaning, which aligns with the baseline of 3.
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 action ('send a push notification') and the target ('paired devices'), distinguishing it from the sibling device-management tools. It also states the triggering user intent ('asks to be notified about something'), making the purpose unambiguous.
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?
The description explicitly tells the agent when to use the tool ('Use this when the user asks to be notified about something'). It does not describe exclusions or alternatives, but no sibling tool performs notification sending, so the guidance is sufficient.
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. Dates show when Glama detected each change.
v2.2.0check_pairing_statusget_historyget_quotaget_setup_statuslist_devicespair_deviceremove_devicesend_notificationMost tools target clearly distinct actions: pairing, sending, history, quota, and device management. The only mild overlap is between check_pairing_status and get_setup_status, but their descriptions differentiate an in-progress QR scan from overall readiness.
All tool names follow a consistent verb_noun pattern in snake_case, such as pair_device, send_notification, get_history, and remove_device. The verbs are clear and the pattern is predictable throughout.
Eight tools is a well-scoped size for a notification server, covering setup, sending, status, history, quota, and device management without unnecessary redundancy. Each tool earns its place.
The surface covers the full notification lifecycle: pairing, setup verification, sending, history, quota monitoring, device listing, and device removal. No obvious blocking gaps exist for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Push notifications for AI agents - send instant iPhone notifications from any MCP client.
Reach your own phone from an AI agent: notifications, approval questions, reminders, ring, files.
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Create Tasks and run Workflows in Bleep from Claude, ChatGPT, and other AI assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/box7e7/mcp-notify'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
