Loading ToolBench
MCP server that lets AI agents send Blipr push alerts to your phone — your agent can page you.
Blipr MCP demonstrates solid tool design with clear, action-oriented naming (send_alert, send_critical, ask, request_ack, check_reply) and comprehensive descriptions (avg 250+ chars). All 5 tools have explicit Zod schemas with typed parameters and descriptions. However, output schemas are not formally documented, responses are returned as JSON strings rather than structured objects with declared fields. Error handling is present but generic (catches and returns error.message without categorization or recovery guidance). The server correctly uses verb_noun naming and includes dependency hints (e.g., 'call check_reply with the returned message_id'). Missing: per-parameter validation rules in descriptions (e.g., 'timeout_seconds must be 1 - 300'), explicit output field documentation, and error classification (retryable vs. fatal).
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.
Look up whether the human has replied to a question or acknowledgement request, without blocking. Use this to resume an earlier ask or request_ack that timed out or was cancelled by the client. Returns the current state immediately (or after a brief optional long-poll). Replies are retained for ~30 minutes.
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).
Output schemas not formally documented. Tools return JSON strings (e.g., JSON.stringify(result)) rather than structured ToolResult objects with declared field types. LLMs cannot infer downstream field names or types without explicit schema documentation.
Error handling lacks categorization and recovery guidance. Catch blocks return (e as Error).message without indicating whether the error is retryable, user-fixable, or fatal. LLMs cannot determine next steps.
Parameter constraints not fully documented in descriptions. timeout_seconds accepts positive integers but lacks explicit range (e.g., 'capped at server max ~300'). priority accepts 1 - 5 but no description of what each level means for user experience.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
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 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.
No dry-run or confirmation pattern for irreversible operations. send_alert and send_critical publish immediately without a preview or confirmation step. Agents cannot verify message content before sending.
check_reply's wait_seconds parameter lacks upper bound documentation in description. Code mentions 'capped at server max ~300' but this constraint is not visible in the parameter description text that LLMs read.