Skip to main content
Glama

Pushary

by com.pushary

Wait for User Answer

wait_for_answer
Read-onlyIdempotent

Poll once for the user's answer to a previously created question: after ask_user times out, after ask_user with wait:false, or with a linkedCorrelationId from send_notification. Each call blocks until the answer arrives or timeoutMs expires (default 30 seconds, max 55). If a live question is still unanswered after this poll, handoffAction is "cancel_then_ask_in_current_client": cancel the phone question before asking in the current chat or client. If cancellation returns handoffAction "stop", stop. Otherwise, if cancellation returns false, poll once for 1 second and honor the answer that won the race. The response distinguishes pending, cancelled, expired, missing, and unavailable states; cancelled and unavailable mean stop rather than re-ask. nextAction retains only its original values for older clients. Returns { answered:true, status:"answered", value } once the user responds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeoutMsNoHow long this one poll blocks, in milliseconds (default 30000, max 55000). Follow handoffAction when present, otherwise nextAction.
correlationIdYesThe correlationId from an earlier ask_user response, or the linkedCorrelationId from a send_notification with an embedded askQuestion

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNoWhat to do next, when there is a next step.
noteNoFree text the user added alongside their answer.
valueNoThe user's answer: "yes" or "no" for confirm, the chosen option for select, the typed text for input. Present only when answered is true.
statusYesThe actual question state. Only pending is a live unanswered wait.
answeredYesTrue once the user responded. False means follow handoffAction when present, otherwise nextAction; do not guess that every unanswered state is a timeout.
nextActionNoBackward-compatible next step for older clients. Follow handoffAction first when present.
handoffActionNoRace-safe directive for updated clients. Takes precedence over nextAction.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed7 schema fields changed
    • 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"
+]
  2. Changed1 schema field changed
    • 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"
+}
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Even though annotations carry readOnlyHint and idempotentHint, the description adds extensive behavioral context: blocking semantics per-poll with 30s default and 55s max, the cancel_then_ask_in_current_client handoff behavior, the one-second re-poll race resolution, the distinct response states (pending, cancelled, expired, missing, unavailable) with 'cancelled/unavailable mean stop, not re-ask' semantics, and a note on legacy clients for nextAction. There is no contradiction with 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 description is long but information-dense — every sentence carries either a behavioral rule or a boundary condition that the agent needs to act correctly. It's front-loaded with the primary purpose and trigger conditions. It is not verbose for its set of distinct facts, though a sentence or two could potentially be tightened if the goal were extreme brevity.

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?

For the actual complexity of a result-style tool with an output schema, the description covers all the important execution nuances: the meaning of each response state, how to handle a live-but-unanswered question, what to do on cancellation calls, and legacy client behavior. It also covers the race-resolution via a follow-up 1s poll. The output-structure detail of the schema rounds out the documentation without leaving open questions.

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?

Parameter semantics is already handled well by the input schema: both the correlationId and the timeoutMs are fully described, including acceptable formats, defaults, and min/max limits in the schema itself. The description echoes those facts and adds the contextual connection to ask_user/send_notification flows, but does not materially exceed what the schema already conveys; the schema gives a 3, and the description's added value is positive but marginal.

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?

A very specific verb+resource: "Poll once for the user's answer to a previously created question". It names the exact trigger conditions (after ask_user times out, after ask_user with wait:false, or with a linkedCorrelationId from send_notification), which sharply differentiates it from the other siblings — especially ask_user, who creates the question rather than polls it.

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 when-to-use conditions are explicit and enumerate the exact predecessor scenarios, so the agent knows precisely when to invoke this instead of the clearly referenced alternatives ask_user and send_notification. The main gap is that it doesn't have an explicit when-not-to-use clause, though the prerequisite 'previously created question' effectively closes that gap by implication.

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

All Pushary toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clearly distinct responsibility: ask_user blocks for an answer, wait_for_answer polls an existing question, cancel_question retracts a pending one, send_notification is one-way, and propose_scope handles a specific scope-ratification workflow. Even though propose_scope is a form of asking, its contract-enforcement semantics are clearly separated from a general ask_user call.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: ask_user, cancel_question, propose_scope, send_notification, wait_for_answer. The naming is predictable and makes the action and target of each tool immediately clear.

Tool Count5/5

Five tools is well-scoped for a push-notification and user-question server. Each tool covers a distinct part of the interaction lifecycle without redundant or filler operations.

Completeness4/5

The core lifecycle is well covered: create a question, wait for an answer, cancel a stale question, send a one-way notification, and propose a scope contract. A minor gap is the lack of a way to list or inspect all pending questions, though wait_for_answer and cancel_question handle the primary workflows adequately.

Resources