blipr-mcp
Send Blipr push alerts to your phone from an AI agent, including blocking human-in-the-loop approval gates.
send_alert— push a notification (priority 1 silent → 5 critical, default 3) with optionaltitle,tags(emoji shortcodes), andclickURL opened on tap.send_critical— priority-5 page for things that can't wait; bypasses silent/Focus when Apple's Critical Alerts entitlement is enabled, otherwise delivered time-sensitive.ask— send a yes/no question and block until the user answers (default 120s timeout); returns{ responded, approved, value, message_id, topic }— branch onapproved, which istrueonly for a Yes.request_ack— send a message the user must explicitly acknowledge; blocks until they tap "Acknowledge" (returnsreplied_atwhen acked).check_reply— non-blocking (or briefly long-polling viawait_seconds) lookup of a reply to an earlierask/request_ack, so you can resume after a timeout or client cancellation (replies kept ~30 min).Topic routing — every blip goes to a topic resolved as:
topicarg → nearest.blipr-topicfile →BLIPR_TOPICenv var, so per-project alerts land separately (self-hosted servers create topics on first publish; blipr.dev requires subscribing first).Deployment — thin stdio MCP client run via
npx -y @blipr/mcp, needing no inbound socket; point it atblipr.devor a self-hostedBLIPR_URL.
Sends push notifications to iOS devices via the Blipr service, supporting standard alerts, critical alerts, and human-in-the-loop approval questions that block until the user responds.
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., "@blipr-mcp Notify me if the database migration fails."
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.
@blipr/mcp
Previously published as
@applogico/blipr-mcp. That package is deprecated; new releases ship as@blipr/mcp. Update your MCP config tonpx -y @blipr/mcp.
An MCP server that lets AI agents send Blipr push alerts to your phone. Your agent finishes a long task, breaks a build, needs approval, or gets stuck — and it pages you. It can also ask you a question and block until you answer, for human-in-the-loop approval gates.
It's a thin stdio client: your MCP host (Claude Code, Cursor, …) launches it,
the agent calls a tool, and this process makes one outbound HTTPS POST to your
Blipr server. No inbound socket, nothing to host.
Claude Code ──stdio──► @blipr/mcp ──POST /blip/<topic>──► blipr.dev ──APNs──► 📱Setup
No install needed — npx fetches it on demand. Point it at a Blipr server
(blipr.dev or your own self-hosted instance).
Claude Code
claude mcp add blipr \
--env BLIPR_URL=https://blipr.dev \
-- npx -y @blipr/mcpCursor / Claude Desktop / any MCP host (JSON)
{
"mcpServers": {
"blipr": {
"command": "npx",
"args": ["-y", "@blipr/mcp"],
"env": {
"BLIPR_URL": "https://blipr.dev"
}
}
}
}Pick a topic (per project, not global)
Every blip goes to a topic, and each project should use its own, so alerts from different projects land separately on your phone. The topic for a call is resolved in this order:
topictool argument — the agent passes it on the call. Always wins..blipr-topicfile — per-project default. Put the topic name on the first line of a.blipr-topicfile in the project root; the server picks up the nearest one from its launch directory upward (#lines are comments).BLIPR_TOPICenv var — global fallback, kept for backward compatibility. Avoid it when one machine hosts several projects: a global default makes every project ping the same topic.
echo my-project-alerts > .blipr-topicThen subscribe to the same topic (my-project-alerts) in the Blipr iOS app,
and you'll get the agent's pushes on your phone. On blipr.dev that subscribe,
made while signed in, is also what creates the topic, so do it before the
agent's first blip: publishing to a topic that does not exist returns 404. A
self-hosted server still creates the topic on the first publish.
Related MCP server: MCP-Pushover Bridge
Configuration
Setting | Default | Description |
|
| Base URL of your Blipr server (hosted or self-hosted). |
| (none) | Per-project default topic, nearest file from the launch directory upward. |
| (none) | Global fallback topic; lowest precedence (see "Pick a topic" above). |
Tools
send_alert
Send a push notification. Parameters:
message(required) — the alert body.title— short bold title.topic— topic to publish to; pass it explicitly (falls back to.blipr-topic, thenBLIPR_TOPIC).priority—1silent ·2low ·3default ·4high (plays a sound, respects Focus) ·5critical (breaks Focus).tags— emoji shortcodes, e.g.["warning"].click— URL opened when the notification is tapped.markdown: render the body as Markdown (bold, italics, links, code). Off by default.
send_critical
A priority-5 page for things that genuinely can't wait. Bypasses silent/Focus
when the Blipr app has Apple's Critical Alerts entitlement enabled; otherwise
it's delivered as time-sensitive. Also takes markdown.
ask — human-in-the-loop yes/no (blocks)
Send a yes/no question to your phone and block until you tap an answer, then return it. This is an approval gate: the agent calls it before doing something consequential or irreversible and waits for your decision instead of guessing.
message(required) — the yes/no question.title— short bold title.topic— topic to publish to; pass it explicitly (falls back to.blipr-topic, thenBLIPR_TOPIC).priority— defaults to4(high) since it needs an answer.tags— emoji shortcodes, e.g.["question"].markdown: render the body as Markdown (bold, italics, links, code). Off by default.timeout_seconds— how long to wait for your answer (default120).
Returns { responded, approved, value, message_id, topic }. Branch on
approved — it is true only when you tapped Yes, and false on No, a
timeout, or an error, so a refusal or non-answer can never be misread as a
go-ahead. On a timeout you get
{ responded: false, approved: false, reason: "timeout", message_id, topic }. If
it times out (or your MCP client cancels the call), you can still answer for
~30 min — pass the returned message_id to check_reply to resume.
Under the hood it publishes with reply: "binary", captures the message id
from the publish response, then long-polls
GET /blip/<topic>/<id>/reply?wait=… until you answer or the timeout
budget runs out.
request_ack — require acknowledgement (blocks)
Send a message that you must acknowledge, and block until you tap
"Acknowledge". Use it when the human has to see and confirm something before
the agent continues. Same parameters as ask; publishes with reply: "ack".
Returns { responded, message_id, topic } plus replied_at when acked, or
{ responded: false, reason: "timeout", … }. As with ask, on a timeout you can
resume later with check_reply and the returned message_id.
check_reply — resume / poll an earlier ask or request_ack
Look up whether you've replied to an earlier ask/request_ack — handy if the
blocking call timed out or your MCP client cancelled it. Pass the message_id
(and topic) it returned; non-blocking by default, or set wait_seconds to
briefly long-poll. Returns { responded, value?, replied_at? } (value is
"yes" / "no" / "ack"). Replies are kept ~30 minutes after the original
message was sent.
Example prompts
"Run the migration, and
send_alertme when it's done — priority 4 if it fails."
"If the nightly backup fails,
send_criticalme with the error — that one can't wait."
"Before you
DROPthe production table,askme to approve it — only proceed if I answer yes."
A concrete approval-gate flow:
Agent: about to delete the prod `events` table → calls
ask("Delete prod `events` table (12M rows)? This cannot be undone.")
… blocks; your phone buzzes …
You: tap "No"
Agent: ask returns { responded: true, approved: false, value: "no" } → aborts the deletion.Develop
npm install
npm run build # → dist/index.js
npm test # vitest: unit (publish, config) + in-memory MCP integration
BLIPR_URL=https://blipr.dev BLIPR_TOPIC=demo node dist/index.js # stdioLicense
MIT © Applogico LLC. This is the open client adapter; the Blipr server is distributed as a container image.
Available Tools
5 toolsaskAsk the human a yes/no question (BLOCKS until they answer)A
Send a yes/no question to the user's phone via Blipr and BLOCK until they tap an answer, then return it. This is a human-in-the-loop approval gate: use it before doing something consequential or irreversible (deleting prod data, force-pushing, spending money, sending an email) — anything where you'd otherwise ask 'should I proceed?'. The call does not return until the human answers or it times out. Returns { responded, approved, value, message_id, topic } — ALWAYS branch on approved: it is true ONLY when the human tapped Yes, and false on No, a timeout, or an error. Never treat a non-approval as a go-ahead. On timeout (or if your client cancels the call) the human may still answer within ~30 min — call check_reply with the returned message_id to resume rather than re-asking.
Inputs: message (required), tags, title, topic, +3 more.
check_replyCheck for a reply to an earlier ask / request_ack (non-blocking by default)A
Look up whether the human has replied to a question or ack you sent earlier — use it to resume after ask/request_ack returned a timeout, or after your client cancelled the blocking call. Pass the message_id (and topic) you got back from that call. Returns immediately by default; set wait_seconds to briefly long-poll. Returns { responded, value?, replied_at? } — value is "yes"/"no" (a yes/no question) or "ack". For an approval gate, only proceed when value === "yes". Replies are kept only ~30 minutes after the original message was sent.
Inputs: message_id (required), topic, wait_seconds.
request_ackRequest the human's acknowledgement (BLOCKS until they ack)A
Send a message that needs the human to acknowledge it, and BLOCK until they tap 'Acknowledge', then return. Use this when the human must see and confirm receipt of something before you continue (a heads-up they have to read, a checkpoint reached, 'I'm about to start the long run'). The call does not return until the human acks or it times out. Returns { responded, message_id, topic } plus replied_at when acked (responded:true), or { responded: false, reason: "timeout" } if no one acks in time. On timeout/cancel, call check_reply with the returned message_id (replies are retained ~30 min).
Inputs: message (required), tags, title, topic, +3 more.
send_alertSend a Blipr alertA
Send a push notification to the user's phone via Blipr. Use this to reach the human: a long task finished, a build broke, you need approval, or you're blocked and need input. Priority 1 (silent) to 5 (critical); defaults to 3.
Inputs: message (required), tags, click, title, +3 more.
send_criticalPage the user (critical)A
Send a priority-5 critical page. Use ONLY for things that genuinely cannot wait (production down, urgent approval, safety). Bypasses silent/Focus when the Blipr app has Apple's Critical Alerts entitlement enabled; otherwise it is delivered as time-sensitive.
Inputs: message (required), title, topic, markdown.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 5 tools
Each tool targets a distinct interaction mode: fire-and-forget alert, critical page, blocking yes/no approval, blocking acknowledgment, and reply polling. The only real overlap is send_alert vs send_critical, since send_alert accepts priority 5 and could emulate a critical page, but the descriptions draw a clear line (send_critical is explicitly gated to 'cannot wait' cases). ask vs request_ack is also well separated by return contract (approved vs acknowledged).
Four of five tools follow a clean verb_noun pattern (send_alert, send_critical, request_ack, check_reply). 'ask' is a bare verb that breaks the pattern, though it is unambiguous and arguably intentional for the primary human-in-the-loop call.
Five tools is well-scoped for a push-notification/approval server, and each one earns its place: two outbound notification tiers, two blocking interaction modes, and one resume mechanism. Nothing feels padded or missing at the structural level.
The surface covers the full lifecycle of a notification: send, escalate, ask, confirm, and recover a timed-out reply via check_reply. Minor gaps remain: questions are strictly yes/no (no free-text reply tool), and there is no way to list pending messages, cancel a sent message, or check delivery status.
Maintenance
Related MCP Connectors
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.
SMS alerts for AI agents and scripts. Text your own phone and read replies. API key required.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables AI assistants to send push notifications through the kweenkl service. Allows users to receive contextual notifications from their AI when tasks are complete or important events occur.12 npmMIT
- AlicenseBqualityDmaintenanceEnables AI assistants to send push notifications to mobile devices via Pushover, allowing users to receive instant alerts for task completions, errors, reminders, and custom messages through their AI conversations.19 npm2MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to send push notifications and interactive alerts to iPhone and Mac devices via the BotBell app. It allows AI to receive user replies and manage notification bots for tasks like alerts, reminders, and remote approvals.26 npm1MIT
- AlicenseBqualityDmaintenanceEnables AI agents to send push notifications to your phone through ntfy, with built-in security controls to prevent data exfiltration. It exposes a single tool notify_user for notifying when tasks complete or need attention.1MIT