Skip to main content
Glama

Elicitly Pro

by ai.elicitly

Ask a human to choose options

elicit_selection

Ask a human to choose one or more options from a caller-supplied list (disambiguation, record matching, picking work items). Async like elicit_approval: returns a pending request decided on the hosted review page; the chosen option ids come back via elicit_result as selectedIds. Options render as rows of a table the Liquid templates and css can customize. Defaults to single-select — raise maxSelections for multi-select.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cssNoCustom CSS injected on the review page to style the option table.
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.
messageYesThe instruction shown above the option list — say what the reviewer is choosing and why.
optionsYesThe choices (1-500). Each option is an object with a required unique `id` (returned in `selectedIds`) plus any extra keys, which `rowTemplate` / `hoverTemplate` can reference (e.g. {{ option.name }}).
rowTemplateNoLiquidJS template producing the <td> cells of one option row; the option is exposed as `option` (e.g. <td>{{ option.name }}</td><td>{{ option.score }}</td>). Default: a single cell of `option.label`, falling back to `option.id`.
hoverTemplateNoLiquidJS template for a per-option hover/details card; the option is exposed as `option`. Omit for no hover card.
maxSelectionsNoMost options the reviewer may pick (default 1 = single-select; clamped to the option count).
minSelectionsNoFewest options the reviewer must pick to submit (default 1; 0 allows none).
footerTemplateNoLiquidJS template producing the table footer rows (no variables). Omit for no footer.
headingTemplateNoLiquidJS template producing the <th> cells of the table header (no variables). Omit for no header row.
expiresInSecondsNoHow long the request stays decidable, in seconds (default 3600, clamped 60-604800 — 1 minute to 7 days).

Output Schema

TableJSON 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. Dates show when Glama detected each change.

  1. Changed14 schema fields changed
    • addedInput schema / properties / css / description
      Added value: +"Custom CSS injected on the review page to style the option table."
    • 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 / footerTemplate / description
      Added value: +"LiquidJS template producing the table footer rows (no variables). Omit for no footer."
    • addedInput schema / properties / headingTemplate / description
      Added value: +"LiquidJS template producing the <th> cells of the table header (no variables). Omit for no header row."
    • addedInput schema / properties / hoverTemplate / description
      Added value: +"LiquidJS template for a per-option hover/details card; the option is exposed as `option`. Omit for no hover card."
    • 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 / maxSelections / description
      Added value: +"Most options the reviewer may pick (default 1 = single-select; clamped to the option count)."
    • addedInput schema / properties / message / description
      Added value: +"The instruction shown above the option list — say what the reviewer is choosing and why."
    • addedInput schema / properties / minSelections / description
      Added value: +"Fewest options the reviewer must pick to submit (default 1; 0 allows none)."
    • addedInput schema / properties / options / description
      Added value: +"The choices (1-500). Each option is an object with a required unique `id` (returned in `selectedIds`) plus any extra keys, which `rowTemplate` / `hoverTemplate` can reference (e.g. {{ option.name }})."
    • addedInput schema / properties / rowTemplate / description
      Added value: +"LiquidJS template producing the <td> cells of one option row; the option is exposed as `option` (e.g. <td>{{ option.name }}</td><td>{{ option.score }}</td>). Default: a single cell of `option.label`, falling back to `option.id`."
    • 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"
+}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare openWorldHint=false, idempotentHint=false, destructiveHint=false. The description adds important behavioral context beyond annotations: the operation is asynchronous, returns a pending request, is decided on the hosted review page, and returns selected IDs through elicit_result. Multi-select defaults are also disclosed. This is solid non-obvious behavior information.

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

Conciseness5/5

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

Three dense sentences front-load the purpose, then flow, then customization and selection defaults. Every sentence adds operational value without repeating schema details. The structure is efficient and scannable for an agent.

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?

The tool has 11 parameters and nested objects, but the schema carries detailed per-parameter descriptions and an output schema exists. The description provides the missing operational context: async behavior, result retrieval path, default selection mode, and template/CSS customization. Nothing essential for correct invocation is left out.

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 baseline is 3. The description adds extra semantic value by noting that options render as table rows, that Liquid templates and CSS can customize rendering, and that maxSelections raises single-select to multi-select. It also clarifies the meaning of option IDs as what comes back in selectedIds.

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?

Description opens with a specific verb and resource: 'Ask a human to choose one or more options from a caller-supplied list', followed by concrete use cases (disambiguation, record matching, picking work items). This clearly identifies what the tool does and distinguishes it from siblings like elicit_approval and elicit_result.

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 description gives clear context for when to use this tool via concrete use cases and explains the async flow ('Async like elicit_approval... decisions come back via elicit_result'). It doesn't explicitly say when not to use alternatives, but the context is strong enough for an agent to route correctly.

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

All Elicitly Pro 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.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