Pushary

Wait for User Answer

wait_for_answer

Read-onlyIdempotent

Read the answer or current state of an existing Pushary question by its correlationId. Waits up to timeoutMs, capped at 55 seconds. Returns answered, the answer when available, status and handoff information. Only pending is a live unanswered question; cancelled, expired, missing and unavailable are terminal states. Does not send another question.

Input Schema

Name	Required	Description	Default
`timeoutMs`	No	How long this one poll blocks, in milliseconds (default 30000, max 55000). Follow handoffAction when present, otherwise nextAction.
`correlationId`	Yes	The correlationId from an earlier ask_user response, or the linkedCorrelationId from a send_notification with an embedded askQuestion

Output Schema

Name	Required	Description
`hint`	No	What to do next, when there is a next step.
`note`	No	Free text the user added alongside their answer.
`value`	No	The user's answer: "yes" or "no" for confirm, the chosen option for select, the typed text for input. Present only when answered is true.
`status`	Yes	The actual question state. Only pending is a live unanswered wait.
`answered`	Yes	True once the user responded. False means follow handoffAction when present, otherwise nextAction; do not guess that every unanswered state is a timeout.
`nextAction`	No	Backward-compatible next step for older clients. Follow handoffAction first when present.
`answerSource`	No	Recorded answering surface, when known. Missing provenance is not proof of a phone answer; sandbox is simulated.
`handoffAction`	No	Race-safe directive for updated clients. Takes precedence over nextAction.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 14, 2026

addedOutput schema / properties / answerSource

Added value: +{
+  "description": "Recorded answering surface, when known. Missing provenance is not proof of a phone answer; sandbox is simulated.",
+  "enum": [
+    "dashboard",
+    "mobile_app",
+    "mobile_background",
+    "decide_page",
+    "live_page",
+    "answer_link",
+    "inbox",
+    "slack",
+    "mac_app",
+    "sandbox"
+  ],
+  "type": "string"
+}

Changed7 schema fields changedAug 24, 2026

changedInput schema / properties / timeoutMs / description

Previous value: -"How long this call blocks, in milliseconds (default 30000, max 55000). Retry with the same correlationId to keep waiting; the question expires 10 minutes after it was asked."New value: +"How long this one poll blocks, in milliseconds (default 30000, max 55000). Follow handoffAction when present, otherwise nextAction."

changedOutput schema / properties / answered / description

Previous value: -"True once the user responded. False means keep polling with the same correlationId, up to 3 times at timeoutMs 55000; it is a timeout on this call, not a refusal."New value: +"True once the user responded. False means follow handoffAction when present, otherwise nextAction; do not guess that every unanswered state is a timeout."

addedOutput schema / properties / handoffAction

Added value: +{
+  "description": "Race-safe directive for updated clients. Takes precedence over nextAction.",
+  "enum": [
+    "cancel_then_ask_in_current_client",
+    "stop"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / hint

Added value: +{
+  "description": "What to do next, when there is a next step.",
+  "type": "string"
+}

addedOutput schema / properties / nextAction

Added value: +{
+  "description": "Backward-compatible next step for older clients. Follow handoffAction first when present.",
+  "enum": [
+    "wait_for_answer",
+    "ask_in_current_client"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / status

Added value: +{
+  "description": "The actual question state. Only pending is a live unanswered wait.",
+  "enum": [
+    "answered",
+    "pending",
+    "cancelled",
+    "expired",
+    "missing",
+    "unavailable"
+  ],
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "answered"
-]New value: +[
+  "answered",
+  "status"
+]

Changed1 schema field changedAug 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "answered": {
+      "description": "True once the user responded. False means keep polling with the same correlationId, up to 3 times at timeoutMs 55000; it is a timeout on this call, not a refusal.",
+      "type": "boolean"
+    },
+    "note": {
+      "description": "Free text the user added alongside their answer.",
+      "type": "string"
+    },
+    "value": {
+      "description": "The user's answer: \"yes\" or \"no\" for confirm, the chosen option for select, the typed text for input. Present only when answered is true.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "answered"
+  ],
+  "type": "object"
+}

First observedJul 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description's added disclosure of the 55-second block cap and the state taxonomy (pending is live; cancelled/expired/missing/unavailable are terminal) is genuine value beyond structured data. It does not state whether repeated polling has rate limits or side effects on server state, but that gap is minor given the annotations.

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 core operation and its cap are front-loaded, and the four sentences are dense with usable information. The return-field enumeration is slightly redundant given the output schema exists, but no sentence is filler.

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?

For a two-parameter polling tool with full schema coverage, annotations, and an output schema, the description covers the essentials: what is read, how long it blocks, and what the return states mean. The return-field listing is the only overlap with the output schema.

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% and both parameters are documented in-schema, including the 55000 ms maximum and the handoffAction/nextAction follow-up instruction. The description repeats the cap and adds the correlationId's originating context, but supplies no format or unit detail the schema lacks; baseline 3 applies.

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 ('Read the answer or current state of an existing Pushary question by its correlationId') and explicitly distinguishes itself from the sibling ask_user with 'Does not send another question.' An agent can select it over ask_user/send_notification without opening any 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?

Establishes the post-ask context through 'an existing Pushary question' and 'the correlationId from an earlier ask_user response,' which tells the agent when this tool applies. It rules out the send case, but does not explicitly name ask_user or offer branching guidance versus siblings like schedule_reminder or cancel_question.

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

All Pushary tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?