Ask the human a yes/no question (BLOCKS until they answer)
askSend a yes/no question to your phone and block for an answer. Use this as a human approval gate before irreversible actions. Always check the 'approved' flag 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
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags / emoji shortcodes, e.g. ["question"]. | |
| title | No | Short title, shown bold above the question. | |
| topic | No | 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. | |
| message | Yes | The yes/no question to ask the human. | |
| priority | No | 1=min/silent … 5=critical. Defaults to 4 (time-sensitive) since it needs an answer. | |
| timeout_seconds | No | How 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). |