What can you do with this server?

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 optional title, tags (emoji shortcodes), and click URL 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 on approved, which is true only for a Yes. * request_ack — send a message the user must explicitly acknowledge; blocks until they tap "Acknowledge" (returns replied_at when acked). * check_reply — non-blocking (or briefly long-polling via wait_seconds) lookup of a reply to an earlier ask/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: topic arg → nearest .blipr-topic file → BLIPR_TOPIC env 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 at blipr.dev or a self-hosted BLIPR_URL.

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 "Deploy 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 Source Related Servers Discussions Admin

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

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.
`markdown`	No	Render the body as Markdown (bold, italics, links, code). Off by default.
`priority`	No	1=min/silent … 5=critical. Defaults to 4 (high) 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 are provided, so the description does all the work and does it well: blocking semantics, timeout behavior, ~30 min reply retention, and the critical warning that `approved` is true only on an explicit Yes and must never be inferred from a timeout or error. Auth and irreversibility concerns are surfaced rather than assumed.

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?

Front-loads the blocking question, then the usage gate, then the return contract and the branching rule. The timeout caveat appears twice (prose and schema) but each repetition is short and the risk warrants it; no filler sentences.

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?

There is no output schema, yet the description enumerates the return fields ({ responded, approved, value, message_id, topic }) and states exactly how to interpret the branch. For a blocking, consequential tool with 7 parameters, nothing an agent needs to call it safely is missing.

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 value beyond the schema by tying `timeout_seconds` behavior to the message_id/check_reply recovery path. It doesn't individually explain title, topic, tags, or priority, but those are fully documented in the schema.

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?

States a precise verb and resource ('send a yes/no question to the user's phone') plus the defining behavior ('BLOCK until they tap an answer'), and the human-in-the-loop approval gate framing distinguishes it from siblings like send_alert 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 Guidelines5/5

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

Names concrete trigger conditions (deleting prod data, force-pushing, spending money, sending email) and gives the alternative path: call check_reply with the returned message_id instead of re-asking. Explicit when-to-use plus a named fallback exceeds the bar.

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.

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.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses non-blocking-by-default behavior, the optional long-poll, the ~30 minute retention window for replies, and the decision rule (only proceed on value === "yes"). The remaining gap is what happens for an unknown/expired message_id (error vs. responded:false), which an agent would want to know.

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

Conciseness4/5

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

Purpose and the resume scenario are front-loaded, and the return-shape and retention sentences each carry real information. It is dense with em-dash asides and slightly packed, but nothing is redundant.

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?

No output schema exists, so the description must explain returns — it does precisely, including the yes/no/ack `value` domain and the approval-gate rule. Retention and polling behavior round it out; only failure behavior for an expired message_id is left implicit.

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 description coverage is 100%, so all three parameters are already documented in the schema. The description reinforces the provenance of `message_id`/`topic` and the long-poll intent of `wait_seconds`, but adds no format or boundary detail beyond what the schema states, so the baseline 3 applies.

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?

States a specific verb and resource ('look up whether the human has replied') and scopes it to a question or ack sent earlier. This clearly separates it from the write-side siblings (ask, request_ack) that create the request being checked.

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?

Names the exact triggering conditions: after `ask`/`request_ack` returned a timeout, or after the client cancelled the blocking call. It also tells the agent to reuse the `message_id` and `topic` from that earlier call, so the entry path is unambiguous.

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

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.
`markdown`	No	Render the body as Markdown (bold, italics, links, code). Off by default.
`priority`	No	1=min/silent … 5=critical. Defaults to 4 (high) 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.4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does it well: it discloses the blocking behavior, the return shape in both outcomes ({responded, message_id, topic, replied_at} vs {responded:false, reason:'timeout'}), the ~30 min reply retention, and the caveat that some MCP clients cancel long calls early. This is behavior an agent could not infer from the schema.

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

Conciseness4/5

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

Front-loads the most important fact (BLOCKS until acknowledgement) and stays to four sentences with no filler. Minor redundancy: the check_reply fallback on timeout is stated twice and also duplicates the timeout_seconds schema description.

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?

No output schema exists, yet the description documents both success and timeout return payloads, the blocking/timeout behavior, and the recovery path. For a 7-parameter blocking call, nothing an agent needs to invoke and recover from it correctly is missing.

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 description coverage is 100%, so every parameter (topic fallback chain, priority defaults, timeout_seconds, markdown) is already documented in the schema. The description reinforces the timeout/cancel consequence but adds no new parameter-level semantics beyond what the schema states. Baseline 3 is appropriate.

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?

States a specific verb+resource (send a message that requires human acknowledgement) plus its defining trait: it BLOCKS until acked. That blocking semantic alone distinguishes it from send_alert/send_critical (fire-and-forget) and ask (which presumably expects a reply rather than a bare receipt), so an agent can select it without opening a schema.

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?

Gives clear triggering conditions with concrete examples ('a heads-up they have to read', 'I'm about to start the long run') and adds recovery guidance: on timeout/cancel call check_reply with the returned message_id. It lacks an explicit when-not-to-use (e.g. don't use for questions that need an answer, or when blocking for 120s will stall a pipeline), which keeps it below a 5.

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.

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.
`markdown`	No	Render the body as Markdown (bold, italics, links, code). Off by default.
`priority`	No	1=min/silent, 2=low, 3=default, 4=high (plays a sound, respects Focus), 5=critical (breaks Focus).

TDQS

A3.8/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 full behavioral burden. It discloses the delivery channel (push to phone) and priority semantics, but says nothing about rate limits, delivery failure behavior, permissions/topic resolution consequences, or what the call returns.

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?

Two tight sentences, with the core action first and the usage triggers immediately after. No filler or repetition of the title.

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?

For a 7-parameter notification tool with a fully documented schema and no output schema, the description covers the essential what-and-when. The remaining gap is post-send behavior (confirmation, failure modes), a minor omission given the schema richness.

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 description coverage is 100%, so the schema already documents all seven parameters, including the priority scale and topic fallback chain. The description merely restates the priority range and adds no syntax or defaulting detail beyond the schema; baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource: 'Send a push notification to the user's phone via Blipr,' which is concrete and unambiguous. It's distinguishable from ask/check_reply by the use cases listed, but it never names or contrasts the sibling tools explicitly, leaving routing to inference.

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 enumerates when to use it: 'a long task finished, a build broke, you need approval, or you're blocked and need input.' That is strong context, but there are no exclusions or guidance on when to prefer send_critical, ask, or request_ack instead.

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.

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.
`markdown`	No	Render the body as Markdown (bold, italics, links, code). Off by default.

TDQS

A4.7/5.0

Behavior5/5

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

Since there are no annotations, the description must carry the burden. It adds crucial behavioral context by explaining the delivery mechanism, specifically that it 'Bypasses silent/Focus' modes under certain entitlements, which is vital for an AI understanding the impact of this call.

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 appropriately sized and highly front-loaded, defining the urgency immediately. It is concise and highly efficient, providing necessary technical details without becoming verbose.

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?

Given the high severity and technical complexity of a critical paging tool, the description provides all necessary context regarding use cases and delivery behavior. Nothing critical is missing from this definition.

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?

The schema description coverage is 100%, meaning the structured fields already define the parameters adequately. The description provides the necessary *context* for the call but adds little semantic value beyond the overall urgency.

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 purpose is crystal clear: 'Send a priority-5 critical page.' It strongly implies its difference from a standard 'alert' by defining it as a high-priority, necessary, and time-critical communication channel.

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 provides extremely strict usage guidelines, advising the agent to use the tool 'ONLY' for genuinely critical scenarios like production downtime, urgent approval, or safety issues. This effectively tells the AI when *not* to use it.

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.

5 tool updatesv0.6.3Oct 29, 2026

Changedask3 fields changed

addedInput schema / properties / markdown

Added value: +{
+  "description": "Render the body as Markdown (bold, italics, links, code). Off by default.",
+  "type": "boolean"
+}

changedInput schema / properties / priority / description

Previous value: -"1=min/silent … 5=critical. Defaults to 4 (time-sensitive) since it needs an answer."New value: +"1=min/silent … 5=critical. Defaults to 4 (high) since it needs an answer."

addedInput schema / properties / timeout_seconds / maximum
```
Added value: +9007199254740991
```

Changedcheck_reply1 field changed
- addedInput schema / properties / wait_seconds / maximum
```
Added value: +9007199254740991
```

Changedrequest_ack3 fields changed

addedInput schema / properties / markdown

Added value: +{
+  "description": "Render the body as Markdown (bold, italics, links, code). Off by default.",
+  "type": "boolean"
+}

changedInput schema / properties / priority / description

Previous value: -"1=min/silent … 5=critical. Defaults to 4 (time-sensitive) since it needs an ack."New value: +"1=min/silent … 5=critical. Defaults to 4 (high) since it needs an ack."

addedInput schema / properties / timeout_seconds / maximum
```
Added value: +9007199254740991
```

Changedsend_alert2 fields changed

addedInput schema / properties / markdown

Added value: +{
+  "description": "Render the body as Markdown (bold, italics, links, code). Off by default.",
+  "type": "boolean"
+}

changedInput schema / properties / priority / description

Previous value: -"1=min/silent, 2=low, 3=default, 4=time-sensitive (breaks Focus), 5=critical."New value: +"1=min/silent, 2=low, 3=default, 4=high (plays a sound, respects Focus), 5=critical (breaks Focus)."

Changedsend_critical1 field changed

addedInput schema / properties / markdown

Added value: +{
+  "description": "Render the body as Markdown (bold, italics, links, code). Off by default.",
+  "type": "boolean"
+}

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

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.2/5.0

Scored 2026-10-29 09:50 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

ActivityActive

ResponsivenessUnresponsive

Resources

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
https://api.kweenkl.com/mcp
Reflecto AOAuth
dev.reflecto
Reach your own phone from an AI agent: notifications, approval questions, reminders, ring, files.
Autonomous Agents Communication Workplace & Productivity
92
https://api.reflecto.dev/mcp
AgentPing
io.github.Noriget
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Communication Email
2
https://ping.mgm-llc.org/mcp
ActivitySmith AOAuth
com.activitysmith
AI agents and scripts reporting back to your iPhone with Push Notifications and Live Activities.
Autonomous Agents Communication Developer Tools
341
https://mcp.activitysmith.com/mcp

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 5 months ago (2026-06-05 21:05 UTC)
1
3 npm
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
2 npm
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 7 months ago (2026-03-23 15:08 UTC)
2
10 npm
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 6 months ago (2026-05-10 21:17 UTC)
1
MIT

@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

Related MCP Connectors

Related MCP Servers

`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