elicit_status

A non-blocking status read for any Pro elicitation request — approval, selection, or proposal — the polling alternative to elicit_await’s long-poll.

When to use

You want the current status now, without waiting — a quick check between other work, or a host whose tool-call budget can’t afford a long-poll. If you have nothing else to do until the decision lands, prefer elicit_await over calling this in a loop.

Input

Parameter	Type	Required	Description
elicitationId	string	yes	The id returned when the request was created.

{ "elicitationId": "…" }

Output

{ "status": "pending" }

• Returns immediately with the current status; never waits.
• Read-only and repeatable — it never consumes the result.

The statuses

Status	Terminal?	Meaning
pending	no	Created and still decidable: no decision yet, and the TTL (expiresInSeconds) has not elapsed. The only status elicit_await waits through.
submitted	no — advances to consumed	The reviewer took the submit action — approved the payload as-is (JSON mode), submitted valid form values, chose from the option list, or submitted proposal changes. The decision is final; the outcome is ready for elicit_result.
declined	no — advances to consumed	The reviewer took the decline action — chose not to proceed with the payload, the option list (“none of these”), or the proposal. Equally final, and equally fetchable: elicit_result reports a decline as a legitimate outcome, so the agent can react to it.
canceled	yes	The requester withdrew the request via elicit_cancel before anyone decided — the plan changed, the question no longer needed answering. The review page shows “withdrawn by the requester” and elicit_result errors (there is no reviewer outcome to fetch).
consumed	yes	elicit_result has fetched the outcome at least once. Re-reads stay legal — elicit_result is an idempotent acknowledge-and-read, and each fetch is recorded in the audit trail. The underlying decision is unchanged (the result still carries decision: "submitted" or "declined").
expired	yes	The TTL elapsed with no decision. The review page no longer accepts one, and elicit_result errors. Computed from the deadline, never stored — and one-directional: a decision made in time is permanent, so a decided request never flips to expired.

pending resolves to exactly one of the four outcomes — a cancel racing a reviewer decision is arbitrated by the same constraint that prevents double decisions, so exactly one wins. Double-bordered states are terminal: nothing ever transitions out of canceled, consumed, or expired.

Statuses name the decision, not the button. Renaming the action buttons via labels (e.g. submit: "Pick this venue") changes what the reviewer sees, never what is recorded: the choice is always submitted or declined, so agents and audit consumers work against one stable vocabulary across every flow. (MCP alignment note: declined deliberately matches the MCP elicitation action for an explicit “no”; a dismissed-without-deciding request is what expired captures; and canceled is reserved for the requester’s own withdrawal — three different endings, three different words.)

Related

• elicit_await — block until the decision lands
• elicit_result — fetch the outcome once decided