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., "@@nextmsg/mcp notify me when the build finishes, use the ci channel"
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.
Official Model Context Protocol (MCP) server and CLI notifier for NextMsg.
npm: npmjs.com/package/@nextmsg/mcp, run it with npx -y @nextmsg/mcp
Source: github.com/nextmsg-app/mcp
Guides: nextmsg.app/guides (Claude Code, Cursor, Codex, Antigravity, GitHub Actions, AWS and more)
NextMsg is a one-way push notification inbox for developers. AI agents, autonomous scripts, and long-running workflows use it to notify your phone when tasks finish, fail, or need attention.
Add to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"nextmsg": {
"command": "npx",
"args": ["-y", "@nextmsg/mcp"],
"env": {
"NEXTMSG_KEY": "nextmsg_live_YOUR_KEY_HERE"
}
}
}
}Go to Settings → Features → MCP Servers → Add New MCP Server:
Name: nextmsg
Type: command
Command: npx -y @nextmsg/mcp
Set environment variable NEXTMSG_KEY to your send key.
You can also set up a hook in ~/.claude/settings.json so Claude Code pings your phone whenever it finishes a turn. Set NEXTMSG_KEY in your shell profile (or in the env block of settings.json):
{
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "npx -y @nextmsg/mcp 'Claude Code finished task' --channel claude-code"
}
]
}
]
}
}Send messages directly from your terminal or CI pipelines:
# Set your key once
export NEXTMSG_KEY="nextmsg_live_..."
# Send alert
npx @nextmsg/mcp "Model training complete: loss 0.12" --channel ml
# A message that starts with "-"
npx @nextmsg/mcp -- "-1 tests failing"--key works too, but prefer NEXTMSG_KEY: a key on the command line ends up in shell history. If a key leaks, rotate it in the app (Settings).
Related MCP server: ntfy-mcp
notify_humanSends a push notification to your phone. The agent uses it when a task finishes, fails or needs your input, and whenever you ask to be notified. Its description tells the agent to:
send one notification per outcome, not progress updates
answer in the conversation instead when you're actively chatting
never include secrets, tokens or personal data (the text shows on the lock screen)
report a failed send in the conversation instead of retrying
Parameters:
message (string, required): Alert text (1–640 characters). Supports markdown (**bold**, *italic*, ~~strike~~, `code`). Links are inert text.
channel (string, optional, default: "general"): Channel category tag (1–32 lowercase chars a-z0-9_-). E.g. ci, deploy, ml, infra.
The send key is read only from the NEXTMSG_KEY environment variable, never from tool arguments, so it never passes through the model's context or transcripts.
Send a push notification to the user's phone via NextMsg. Use it when an autonomous task, build, test run, deployment or long-running workflow finishes, fails, or needs the user's input, and whenever the user asks to be notified. Send one notification per outcome, not progress updates. Don't use it to answer a user who is actively chatting with you. Never include secrets, tokens or personal data: the text appears on the lock screen. Keep it short and specific: what happened, where, and what (if anything) the user should do. If sending fails, tell the user in the conversation instead of retrying.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Optional channel to group messages, e.g. ci, deploy, infra, ml. 1-32 lowercase characters [a-z0-9_-]. | general |
| message | Yes | The notification text (1-640 characters). Supports **bold**, *italic*, ~~strikethrough~~ and `code`. Links are shown as plain text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses the delivery path (push to phone via NextMsg), the visibility side effect (text appears on the lock screen, hence no secrets/tokens/personal data), and failure handling (do not retry; report in the conversation instead). These are exactly the non-obvious behaviors an agent needs before calling.
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?
Purpose is front-loaded in the first sentence, and each subsequent sentence delivers a distinct rule (when to use, when not to, privacy, content style, failure handling) with no repetition. Length is justified by the breadth of guidance packed into it.
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 two-parameter notification tool with no annotations and no output schema, everything an agent needs is present: purpose, triggers, exclusions, content constraints, privacy limits, and failure behavior. Nothing material 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?
Schema coverage is 100%, so both `channel` and `message` are already documented, setting the baseline at 3. The description adds content guidance for `message` (what happened, where, and what the user should do; keep it short and specific) and an input constraint (never include secrets), which goes slightly beyond the schema's format description.
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 specific verb, resource, and delivery mechanism ("Send a push notification to the user's phone via NextMsg") in the first sentence. There are no sibling tools to disambiguate from, and the scope is unambiguous without opening the schema.
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 enumerates the triggering conditions (autonomous task, build, test run, deployment or long-running workflow that finishes, fails, or needs input; or a direct user request) and an exclusion ("Don't use it to answer a user who is actively chatting with you"). It also gives a frequency rule ("one notification per outcome, not progress updates"), leaving little to inference.
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.
v1.0.2notify_humanScored across 1 tool
With only one tool there is no possibility of confusing it with another; its trigger conditions (task finished, failed, or needs input) and non-triggers (active chat, progress updates) are spelled out. Selection is unambiguous.
A single name, notify_human, follows a clean verb_noun snake_case convention. There is no competing convention to create inconsistency.
The server's stated purpose is narrow (send a push notification), so one tool is defensible, but a single tool is on the thin side for a standalone server. It earns its place but leaves little surface area.
For a one-way notification service, the core operation is covered and the description explains failure handling (report in conversation, don't retry). Minor gaps like checking delivery status or listing notification history are absent, but not essential to the purpose.
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Reach your own phone from an AI agent: notifications, approval questions, reminders, ring, files.
Push notifications for AI agents - send instant iPhone notifications from any MCP client.
Send mobile pings and route human questions, approvals, and handoffs from AI agents.
