Skip to main content
Glama

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

request_ack

Send a notification that requires human acknowledgment and pauses execution until the user confirms receipt, ensuring critical messages are seen before continuing.

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

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoTags / emoji shortcodes, e.g. ["eyes"].
titleNoShort title, shown bold above the message.
topicNoTopic to publish to. Defaults to the BLIPR_TOPIC env var.
messageYesWhat the human needs to see and acknowledge.
priorityNo1=min/silent … 5=critical. Defaults to 4 (time-sensitive) 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).
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description fully discloses the blocking nature, timeout, return values for both ack and timeout, and fallback to check_reply. Since no annotations are provided, the description carries the full burden and does so completely.

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?

The description is well-structured with key info first, then examples, then return format. It is concise without being overly verbose, though there is minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return values and error handling. It references check_reply for timeout/cancel. The parameter descriptions are in schema, so the description focuses on behavior, making it fairly complete.

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 coverage is 100%, so the schema already documents all parameters. The description adds minimal parameter-specific info (e.g., timeout_seconds mentions cancellation and check_reply), but largely relies on schema. 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?

The description clearly states the tool sends a message that requires human acknowledgement and blocks until acknowledged. It uses specific verbs like 'send' and 'block', and distinguishes from siblings by focusing on blocking behavior.

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?

The description provides examples of when to use this tool (heads-up, checkpoint, before long run) and explains the blocking behavior. It doesn't explicitly state when not to use it, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/applogico/blipr-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server