What can you do with this server?

The @blipr/mcp server lets AI agents send push notifications and engage in human-in-the-loop workflows via the Blipr iOS app. * Send push alerts (send_alert): Push a notification to your phone with a message, optional title, priority (1=silent to 5=critical), emoji tags, and a tap-to-open URL — useful for task completions, build failures, or status updates. * Send critical pages (send_critical): Fire a priority-5 urgent alert that bypasses Focus/silent modes — reserved for genuinely time-sensitive situations like production outages. * Ask yes/no questions and block for answer (ask): Pose a binary question to your phone and block execution until you tap Yes or No — acts as an approval gate before consequential actions (e.g., dropping a table, force-pushing, spending money). * Request acknowledgement and block (request_ack): Send a message requiring explicit acknowledgement and block until the user taps "Acknowledge" — useful for checkpoints or confirming the human has seen something before the agent proceeds. * Check replies to earlier prompts (check_reply): Non-blockingly poll for a reply to an earlier ask/request_ack that timed out or was cancelled — replies are retained ~30 minutes, so the agent can resume without re-asking. * Per-project topic routing: Direct alerts to specific topics (via tool argument, .blipr-topic file, or BLIPR_TOPIC env var) so notifications from different projects land in separate channels on your phone.

Which integrations are available for this server?

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.

How do I use blipr-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. 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

by applogico

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@blipr/mcp

npm version 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:

topic tool argument — the agent passes it on the call. Always wins.
.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).
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.

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

`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"].
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.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Tags / emoji shortcodes, e.g. ["question"].
`title`	No	Short title, shown bold above the question.
`topic`	No	Topic to publish to. Pass it explicitly — each project should use its own topic. When omitted, falls back to the project's `.blipr-topic` file, then the BLIPR_TOPIC env var.
`message`	Yes	The yes/no question to ask the human.
`priority`	No	1=min/silent … 5=critical. Defaults to 4 (time-sensitive) since it needs an answer.
`timeout_seconds`	No	How long to block waiting for the answer before giving up. Defaults to 120s. Some MCP clients cancel a long tool call before this elapses; on timeout or cancel, use check_reply with the returned message_id (replies are retained ~30 min).

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description fully discloses blocking nature, timeout behavior, return structure, and that approval is only true on Yes. Also mentions persistence of replies for ~30 minutes and cancellation handling. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single well-structured paragraph: first sentence states purpose, then usage guidelines, return format, timeout instructions. No wasted words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters, no output schema, and no annotations, the description covers all necessary information: blocking, return shape, edge cases (timeout, cancellation), and follow-up via check_reply. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes all 6 parameters (100% coverage). Description adds context beyond schema: explains default priority (4) reasoning, how topic fallback works, and that message_id is used for later checking. Adds meaningful guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it asks a yes/no question and blocks for answer. Distinguishes from siblings like send_alert (one-way) and check_reply (polling) by emphasizing its role as a blocking approval gate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly specifies 'use it before doing something consequential or irreversible' and gives concrete examples (deleting prod data, force-pushing). Provides when-not: on timeout, use check_reply instead of re-asking. Warns against treating non-approval as go-ahead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description
`topic`	No	Topic the original message was sent to. Pass it explicitly when you passed one on the original call; otherwise it falls back to the same default (`.blipr-topic` file, then the BLIPR_TOPIC env var).
`message_id`	Yes	The message_id returned by a prior ask / request_ack call.
`wait_seconds`	No	Seconds to long-poll for an answer (0 = instant check; default 0).

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description fully carries the burden. Discloses non-blocking default behavior, immediate return vs long-polling via wait_seconds, return object format, and 30-minute reply retention. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single well-structured paragraph that starts with purpose, then usage, then parameter details, then return value and retention. Every sentence provides necessary information without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations or output schema, description is thorough. Covers parameters, return format, retention, and usage. Minor gap: no mention of error cases or null fields, but not critical for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all three parameters with descriptions. Description adds value: explains that message_id comes from prior calls, topic defaults to file/env var, and clarifies when to pass topic explicitly. Exceeds baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool checks for replies to a prior ask/request_ack. Distinguishes from siblings by specifying its role as a follow-up to timeouts or cancellations, complementing send_alert, send_critical, ask, and request_ack.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes when to use: after a timeout from ask/request_ack or after client cancellation. Provides guidance on interpreting the response for approval gates. Lacks explicit 'when not to use' but context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

ParametersJSON Schema

Name	Required	Description
`tags`	No	Tags / emoji shortcodes, e.g. ["eyes"].
`title`	No	Short title, shown bold above the message.
`topic`	No	Topic to publish to. Pass it explicitly — each project should use its own topic. When omitted, falls back to the project's `.blipr-topic` file, then the BLIPR_TOPIC env var.
`message`	Yes	What the human needs to see and acknowledge.
`priority`	No	1=min/silent … 5=critical. Defaults to 4 (time-sensitive) since it needs an ack.
`timeout_seconds`	No	How long to block waiting for the acknowledgement before giving up. Defaults to 120s. Some MCP clients cancel a long tool call early; on timeout or cancel, use check_reply with the returned message_id (replies are retained ~30 min).

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses blocking behavior, timeout behavior, return values on success and failure, and retention of replies for ~30 min via check_reply. It also notes potential early cancellation by MCP clients, providing comprehensive behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured paragraph of ~100 words. It front-loads the primary purpose, then provides use cases, return format, and timeout guidance without unnecessary repetition or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description thoroughly explains return values, required parameters, optional parameters with usage scenarios, and fallback behavior (check_reply). It covers all aspects needed for correct invocation, given the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds useful context beyond the schema for the 'topic' parameter (use explicit topic per project) and 'timeout_seconds' parameter (default 120s, cancellation behavior). This incremental value justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description clearly state the tool sends a message requiring human acknowledgement and blocks until receipt. It specifies the verb (send/request), resource (human acknowledgement), and blocking behavior, differentiating from siblings by emphasizing the blocking and ack requirement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool (when the human must see and confirm receipt) and provides concrete examples (heads-up, checkpoint, about to start long run). It also mentions the alternative check_reply on timeout, offering clear guidance on when it is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Tags / emoji shortcodes, e.g. ["warning", "rocket"].
`click`	No	URL opened when the notification is tapped.
`title`	No	Short title, shown bold above the message.
`topic`	No	Topic to publish to. Pass it explicitly — each project should use its own topic. When omitted, falls back to the project's `.blipr-topic` file, then the BLIPR_TOPIC env var.
`message`	Yes	The alert body — what happened or what you need.
`priority`	No	1=min/silent, 2=low, 3=default, 4=time-sensitive (breaks Focus), 5=critical.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses that it sends push notifications and defines priority scale (1-5, default 3). However, it does not detail rate limits, authentication, or side effects beyond the basic action. This is adequate for a simple notification tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two sentences. The first states the core action, the second provides usage context and priority info. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers usage scenarios and priority, but with 6 parameters and no output schema, it could be more complete. Schema descriptions handle parameter details, so this is acceptable. However, the return value or success behavior is not mentioned, leaving some ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining priority range and default, but does not elaborate on tags, click, title, or topic beyond what the schema provides. Minimal additional insight.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sends push notifications via Blipr and provides specific use cases (e.g., long task finished, build broke) that distinguish it from siblings like 'send_critical' or 'ask'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete examples of when to use (long task finished, build broke, need approval, blocked) and mentions priority default. It does not explicitly state when not to use or name alternatives, but the examples are effective.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description
`title`	No	Short title.
`topic`	No	Topic to publish to. Pass it explicitly — each project should use its own topic. When omitted, falls back to the project's `.blipr-topic` file, then the BLIPR_TOPIC env var.
`message`	Yes	What is wrong or what you need, urgently.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full disclosure burden. It explains that it bypasses silent/Focus under certain conditions and falls back to time-sensitive delivery, which is key behavioral detail. Missing are aspects like confirmation, side effects, or permissions, but core delivery 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, no fluff, and immediately conveys purpose, restrictions, and a key behavioral nuance. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (3 params, no output schema), the description covers purpose, usage guidance, and a significant behavioral detail. It does not explain return values or side effects, but for a notification tool, these are often implicit. The presence of sibling tools provides context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter has a clear description. The tool description adds little beyond the schema (e.g., 'Short title,' 'urgently' for message). The topic parameter's fallback logic is detailed in the schema, so the description does not significantly enhance semantic meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Send a priority-5 critical page,' using a specific verb and resource. It distinguishes from sibling tools like send_alert by emphasizing urgency and criticality, and explains behavior with Apple's Critical Alerts entitlement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use ONLY for things that genuinely cannot wait (production down, urgent approval, safety),' which frames the appropriate context clearly. It lacks explicit mention of when not to use it or alternatives, but the strong 'ONLY' provides effective guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.4.0Jul 30, 2026

Changedask1 field changed

changedInput schema / properties / topic / description

Previous value: -"Topic to publish to. Defaults to the BLIPR_TOPIC env var."New value: +"Topic to publish to. Pass it explicitly — each project should use its own topic. When omitted, falls back to the project's `.blipr-topic` file, then the BLIPR_TOPIC env var."

Changedcheck_reply1 field changed

changedInput schema / properties / topic / description

Previous value: -"Topic the original message was sent to. Defaults to the BLIPR_TOPIC env var."New value: +"Topic the original message was sent to. Pass it explicitly when you passed one on the original call; otherwise it falls back to the same default (`.blipr-topic` file, then the BLIPR_TOPIC env var)."

Changedrequest_ack1 field changed

changedInput schema / properties / topic / description

Previous value: -"Topic to publish to. Defaults to the BLIPR_TOPIC env var."New value: +"Topic to publish to. Pass it explicitly — each project should use its own topic. When omitted, falls back to the project's `.blipr-topic` file, then the BLIPR_TOPIC env var."

Changedsend_alert1 field changed

changedInput schema / properties / topic / description

Previous value: -"Topic to publish to. Defaults to the BLIPR_TOPIC env var."New value: +"Topic to publish to. Pass it explicitly — each project should use its own topic. When omitted, falls back to the project's `.blipr-topic` file, then the BLIPR_TOPIC env var."

Changedsend_critical1 field changed

changedInput schema / properties / topic / description

Previous value: -"Topic. Defaults to BLIPR_TOPIC."New value: +"Topic to publish to. Pass it explicitly — each project should use its own topic. When omitted, falls back to the project's `.blipr-topic` file, then the BLIPR_TOPIC env var."

5 tool updatesv0.3.1Jun 30, 2026
- First observedask
- First observedcheck_reply
- First observedrequest_ack
- First observedsend_alert
- First observedsend_critical

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool serves a distinct purpose: send_alert for general notifications, send_critical for urgent pages, ask for blocking yes/no questions, request_ack for blocking acknowledgments, and check_reply for polling for previous replies. No overlap.

Naming Consistency4/5

Most tools follow a verb_noun pattern (send_alert, send_critical, request_ack, check_reply), but 'ask' is a simple verb without a noun, deviating slightly from the pattern.

Tool Count5/5

With 5 tools, the set is lean and focused on notification and human-in-the-loop workflows. Each tool adds necessary functionality without redundancy.

Completeness5/5

The tools cover sending alerts of varying priority, blocking questions and acknowledgments, and polling for replies. This provides a full lifecycle for notification and approval interactions.

Maintenance

ActivityActive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

kweenkl-mcp A
io.github.antoinedelorme
Push notifications for AI agents - send instant iPhone notifications from any MCP client.
Communication App Automation
62
Reflecto AOAuth
dev.reflecto
Reach your own phone from an AI agent: notifications, approval questions, reminders, ring, files.
Autonomous Agents Communication Workplace & Productivity
92
AgentPing
io.github.Noriget
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Communication Email
2
SenderKitOAuth
com.senderkit
Build and send email, SMS, and push straight from your AI agent.
Email Communication
31

Related MCP Servers

kweenkl MCP Server
Communication App Automation
antoinedelorme
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.
Updated 3 months ago (2026-06-05 21:05 UTC)
1
17
MIT
MCP-Pushover Bridge
Communication App Automation
pyang2045
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.
Updated a year ago (2025-06-25 05:30 UTC)
1
20
2
MIT
BotBell MCP Server
Communication App Automation
qq418716640
A
license
A
quality
C
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.
Updated 5 months ago (2026-03-23 15:08 UTC)
2
19
1
MIT
ntfy-mcp
Communication Developer Tools
MahdiHedhli
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.
Updated 4 months ago (2026-05-10 21:17 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/applogico/blipr-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@blipr/mcp

Setup

Claude Code

Cursor / Claude Desktop / any MCP host (JSON)

Pick a topic (per project, not global)

Configuration

Tools

send_alert

send_critical

ask — human-in-the-loop yes/no (blocks)

request_ack — require acknowledgement (blocks)

check_reply — resume / poll an earlier ask or request_ack

Example prompts

Develop

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`send_alert`

`send_critical`

`ask` — human-in-the-loop yes/no (blocks)

`request_ack` — require acknowledgement (blocks)

`check_reply` — resume / poll an earlier ask or request_ack