blipr-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BLIPR_URL | No | Base URL of your Blipr server (hosted or self-hosted). | https://blipr.dev |
| BLIPR_TOPIC | No | Default topic used when a tool call omits one. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_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. |
| send_criticalA | 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. |
| askA | 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 |
| request_ackA | 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 |
| check_replyA | Look up whether the human has replied to a question or ack you sent earlier — use it to resume after |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
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.
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.
With 5 tools, the set is lean and focused on notification and human-in-the-loop workflows. Each tool adds necessary functionality without redundancy.
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.