Skip to main content
Glama

@blipr/mcp

npm version CI license: MIT Node

Previously published as @applogico/blipr-mcp. That package is deprecated; new releases ship as @blipr/mcp. Update your MCP config to npx -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/mcp

Cursor / 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:

  1. topic tool argument — the agent passes it on the call. Always wins.

  2. .blipr-topic file — per-project default. Put the topic name on the first line of a .blipr-topic file in the project root; the server picks up the nearest one from its launch directory upward (# lines are comments).

  3. BLIPR_TOPIC env 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-topic

Then 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

BLIPR_URL (env)

https://blipr.dev

Base URL of your Blipr server (hosted or self-hosted).

.blipr-topic (file)

(none)

Per-project default topic, nearest file from the launch directory upward.

BLIPR_TOPIC (env)

(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, then BLIPR_TOPIC).

  • priority — 1 silent · 2 low · 3 default · 4 high (plays a sound, respects Focus) · 5 critical (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, then BLIPR_TOPIC).

  • priority — defaults to 4 (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 (default 120).

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_alert me when it's done — priority 4 if it fails."

"If the nightly backup fails, send_critical me with the error — that one can't wait."

"Before you DROP the production table, ask me 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   # stdio

License

MIT © Applogico LLC. This is the open client adapter; the Blipr server is distributed as a container image.

Available Tools

5 tools
askAsk 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

    A4.2/5.0

    Scored across 5 tools

    Disambiguation4/5

    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).

    Naming Consistency4/5

    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.

    Tool Count5/5

    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.

    Completeness4/5

    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

    ActivityMaintained
    ResponsivenessLimited data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      B
      quality
      D
      maintenance
      Enables 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.
      1
      2 npm
      MIT
    • A
      license
      B
      quality
      D
      maintenance
      Enables 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.
      1
      9 npm
      2
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      Enables 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.
      2
      6 npm
      1
      MIT
    • A
      license
      B
      quality
      D
      maintenance
      Enables 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.
      1
      MIT