Skip to main content
Glama

Request human approval

elicit_approval

Request human approval before proceeding. Async: returns immediately with a pending request that a human decides later on the hosted review page (block with elicit_await, fetch the outcome with elicit_result); for a synchronous in-session form answered by the connected host, use elicit_form instead. Two modes, at least one of context / requestedSchema is required: (1) json mode — pass context, a read-only payload the reviewer approves or declines as-is; optionally also pass displayTemplate, a LiquidJS template that customizes how context is rendered on the review page (instead of the default raw JSON view); (2) form mode — pass requestedSchema, a JSON Schema restricted to the MCP elicitation requestedSchema subset (MCP 2025-11-25): a flat object whose properties are strings, numbers/integers, booleans, or single/multi-select enums (no nested objects, arrays of objects, $ref, or allOf) — the reviewer fills in these fields on the review page and submits them back as the submitted data. Both may be passed together: context (optionally rendered via displayTemplate) is then displayed as read-only context above the form (it is NOT merged into or used to pre-fill the form fields, which are seeded only from requestedSchema defaults). Per the MCP elicitation spec, form mode MUST NOT be used to request secrets, credentials, or other sensitive information from the reviewer.

Input Schema

NameRequiredDescriptionDefault
labelsNoRelabel or localize the action buttons (submit, decline). Each label is trimmed, 1-40 characters; unknown keys are rejected. Button placement and styling stay fixed.
contextNojson mode: a read-only JSON payload the reviewer approves or declines as-is. Echoed back verbatim in elicit_result. Rendered as raw JSON unless `displayTemplate` is given.
messageYesThe prompt shown to the reviewer at the top of the review page — say what needs approving and why.
displayTemplateNoOptional LiquidJS template that customizes how `context` is rendered on the review page. `context` is exposed to the template under the `context` key (e.g. {{ context.recordId }}).
requestedSchemaNoform mode: JSON Schema in the MCP elicitation requestedSchema subset (flat object of string / number / integer / boolean / enum properties — no nested objects, arrays of objects, $ref, or allOf). The reviewer fills these fields on the review page; property `default`s seed the form.
expiresInSecondsNoHow long the request stays decidable, in seconds (default 3600, clamped 60-604800 — 1 minute to 7 days).

Output Schema

NameRequiredDescriptionDefault
statusYesAlways `pending` at creation.
expiresAtYesWhen the request stops being decidable (timestamp).
reviewUrlYesURL of the hosted review page where a human decides this request.
elicitationIdYesUnique id of the created request — pass it to elicit_await / elicit_status / elicit_result / elicit_cancel.
elicitationDeliveredYesTrue when the request was also pushed to the connected client as a url-mode elicitation; when false, surface `reviewUrl` to the human yourself.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / additionalProperties
      Previous value: -falseNew value: +{}
  2. Changed1 schema field changed
    • changedInput schema / properties / displayTemplate / maxLength
      Previous value: -20000New value: +32768
  3. Changed8 schema fields changed
    • addedInput schema / properties / context / description
      Added value: +"json mode: a read-only JSON payload the reviewer approves or declines as-is. Echoed back verbatim in elicit_result. Rendered as raw JSON unless `displayTemplate` is given."
    • addedInput schema / properties / expiresInSeconds / description
      Added value: +"How long the request stays decidable, in seconds (default 3600, clamped 60-604800 — 1 minute to 7 days)."
    • addedInput schema / properties / labels / description
      Added value: +"Relabel or localize the action buttons (submit, decline). Each label is trimmed, 1-40 characters; unknown keys are rejected. Button placement and styling stay fixed."
    • addedInput schema / properties / labels / properties / decline / description
      Added value: +"Replacement label for the decline button."
    • addedInput schema / properties / labels / properties / submit / description
      Added value: +"Replacement label for the submit button."
    • addedInput schema / properties / message / description
      Added value: +"The prompt shown to the reviewer at the top of the review page — say what needs approving and why."
    • addedInput schema / properties / requestedSchema / description
      Added value: +"form mode: JSON Schema in the MCP elicitation requestedSchema subset (flat object of string / number / integer / boolean / enum properties — no nested objects, arrays of objects, $ref, or allOf). The reviewer fills these fields on the review page; property `default`s seed the form."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "elicitationDelivered": {
      +      "description": "True when the request was also pushed to the connected client as a url-mode elicitation; when false, surface `reviewUrl` to the human yourself.",
      +      "type": "boolean"
      +    },
      +    "elicitationId": {
      +      "description": "Unique id of the created request — pass it to elicit_await / elicit_status / elicit_result / elicit_cancel.",
      +      "type": "string"
      +    },
      +    "expiresAt": {
      +      "description": "When the request stops being decidable (timestamp).",
      +      "type": "string"
      +    },
      +    "reviewUrl": {
      +      "description": "URL of the hosted review page where a human decides this request.",
      +      "type": "string"
      +    },
      +    "status": {
      +      "const": "pending",
      +      "description": "Always `pending` at creation.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "elicitationId",
      +    "status",
      +    "reviewUrl",
      +    "expiresAt",
      +    "elicitationDelivered"
      +  ],
      +  "type": "object"
      +}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover only openWorld/idempotent/destructive hints, and the description adds substantially more: returns immediately with a pending request decided later, the hosted review page flow, the MCP spec prohibition on requesting secrets/credentials in form mode, and the fact that `context` is not merged into or used to pre-fill form fields. That last point is exactly the kind of behavioral trap an agent would otherwise get wrong.

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?

It is long, but front-loaded with the async-vs-sync decision and organized into clearly marked modes, so no sentence is filler. It could be tightened slightly (the MCP-version parenthetical and repeated subset restatements), but the density is justified by the behavioral traps it prevents.

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?

With an output schema present, return values need not be explained, and the description still covers the async lifecycle, both modes, the schema subset restriction, the sensitive-data prohibition, and the alternative tools. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description materially enriches several params: `context` is echoed verbatim and rendered as raw JSON unless `displayTemplate` is given, `displayTemplate` is a LiquidJS template with `context` exposed under the `context` key, and `requestedSchema` is constrained to the flat MCP subset with defaults seeding the form. `labels` and `expiresInSeconds` are left entirely to the schema, which is the only small gap.

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?

Opens with a specific verb+resource ('Request human approval') and immediately scopes it against siblings by naming elicit_await, elicit_result, and elicit_form with the condition that selects each. An agent can tell this apart from the other twelve elicit_* tools without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: async mode blocks via elicit_await and fetches via elicit_result, while synchronous in-session forms belong to elicit_form. It also states the precondition that at least one of `context`/`requestedSchema` is required and when to pick each mode (including passing both together).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources