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