Skip to main content
Glama
applogico

blipr-mcp

by applogico
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Ask the human a yes/no question (BLOCKS until they answer)

ask

Send a yes/no approval question to the user's phone via Blipr and block until they answer, so agents can confirm consequential or irreversible actions before proceeding.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
tagsNoTags / emoji shortcodes, e.g. ["question"].
titleNoShort title, shown bold above the question.
topicNoTopic 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.
messageYesThe yes/no question to ask the human.
markdownNoRender the body as Markdown (bold, italics, links, code). Off by default.
priorityNo1=min/silent … 5=critical. Defaults to 4 (high) since it needs an answer.
timeout_secondsNoHow 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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.6.3
    • 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
  2. Changed1 schema field changedv0.4.0
    • 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."
  3. First observedv0.3.1

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.

Deploy Server

Other Tools