Skip to main content
Glama
applogico

blipr-mcp

by applogico
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Request the human's acknowledgement (BLOCKS until they ack)

request_ack

Send a message that requires human acknowledgement and block until they tap Acknowledge, ensuring agents pause before continuing after critical checkpoints.

Instructions

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

Input Schema

NameRequiredDescriptionDefault
tagsNoTags / emoji shortcodes, e.g. ["eyes"].
titleNoShort title, shown bold above the message.
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.
messageYesWhat the human needs to see and acknowledge.
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 ack.
timeout_secondsNoHow 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).

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

Deploy Server

Other Tools