Elicitly Pro

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

TableJSON Schema

Name	Required	Description
`labels`	No	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.
`context`	No	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.
`message`	Yes	The prompt shown to the reviewer at the top of the review page — say what needs approving and why.
`displayTemplate`	No	Optional 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 }}).
`requestedSchema`	No	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.
`expiresInSeconds`	No	How long the request stays decidable, in seconds (default 3600, clamped 60-604800 — 1 minute to 7 days).

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes	Always `pending` at creation.
`expiresAt`	Yes	When the request stops being decidable (timestamp).
`reviewUrl`	Yes	URL of the hosted review page where a human decides this request.
`elicitationId`	Yes	Unique id of the created request — pass it to elicit_await / elicit_status / elicit_result / elicit_cancel.
`elicitationDelivered`	Yes	True 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. Dates show when Glama detected each change.

Changed8 schema fields changedSep 5, 2026

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"
+}

First observedSep 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The annotations are minimal (openWorldHint, idempotentHint, destructiveHint all false), so the description carries the burden of behavioral disclosure. It thoroughly explains the async 'returns immediately with a pending request' behavior, the differences between json and form modes, the fact that context is read-only and echoed back verbatim, that context does not pre-fill form fields, and that defaults seed the form. It also discloses the expiration behavior in the schema. It doesn't explicitly discuss rate limits or failure modes, but the described behaviors are substantial and beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and information-rich, but it is quite long and packs many details into one paragraph. It is front-loaded with the core purpose and the key distinguishing sibling reference, which is good. However, the form-mode restrictions and mode-by-mode explanations could be structured more cleanly. It earns a 3 because while every sentence carries information, the wall-of-text format makes it harder for an agent to quickly parse the key decision points.

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 a complex 6-parameter tool with nested objects and an output schema, the description is remarkably complete. It covers the async behavior, the two modes, parameter relationships, constraints from the MCP spec, security limitations (no secrets in form mode), and points to sibling tools for follow-up operations. An agent would have all the information needed to select and invoke this tool correctly.

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 description coverage is 100%, so the schema already documents all 6 parameters. The description adds meaningful semantic value by explaining the relationship between context and displayTemplate, the implications of requestedSchema (flat object, defaults seeding the form), and the exact behavior of context in form mode (NOT merged into form fields). It also clarifies the required-ness of context/requestedSchema ('at least one is required') beyond what the schema shows. This goes beyond just repeating schema descriptions.

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?

The description clearly states the tool's purpose: 'Request human approval before proceeding.' It uses a specific verb (request) and resource (human approval), and immediately distinguishes it from sibling tools like elicit_await, elicit_result, and elicit_form. It comprehensively describes the two operating modes (json mode and form mode), making it unambiguous what this tool does and how it differs from related tools.

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?

The description explicitly provides usage guidance: it states when to use this tool (before proceeding with an operation needing human approval), describes the async vs sync distinction, and explicitly names alternatives (`elicit_await` for blocking, `elicit_result` for fetching outcome, `elicit_form` for synchronous in-session form). It also gives a clear constraint: 'form mode MUST NOT be used to request secrets, credentials, or other sensitive information.' This is exemplary usage guidance.

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

All Elicitly Pro tools Inspect

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.1/5.0

Disambiguation3/5

Most tools have distinct roles in the elicitation lifecycle, but elicit_approval's form mode heavily overlaps with elicit_form, and elicit_confirm is explicitly a wrapper over elicit_form, creating real selection ambiguity. Status, await, result, cancel, and history are clearly separated, so the confusion is limited to a couple of closely related tools.

Naming Consistency4/5

All tools share the elicit_ prefix and use snake_case, which makes the namespace predictable and easy to scan. However, the second token mixes nouns (approval, form, proposal, status) with verbs (await, cancel, confirm, ping), and elicit_doctor is a non-obvious metaphor, so the pattern is not perfectly uniform.

Tool Count5/5

Twelve tools is within the ideal scope for a specialized elicitation server: creation variants, status polling, blocking wait, result retrieval, cancellation, history, and diagnostic helpers all have a place. The count feels purposeful rather than padded, and it fits the domain without becoming unwieldy.

Completeness4/5

The lifecycle is well covered: agents can create varied elicitations, check status, block on decisions, fetch results, cancel pending requests, and review history, plus diagnostic and connectivity tools. The main gap is the inability to update or extend a pending elicitation after creation, but agents can work around this by canceling and recreating.

Resources

Need Help?