Skip to main content
Glama

Elicitly Pro

by ai.elicitly

Propose a record change for review

elicit_proposal

Ask a human to review, edit, and selectively approve a proposed record create-or-update, shown as a diff grid: one or more read-only Source columns, a read-only Current column, and an editable Proposed column. Async like elicit_approval: returns a pending request decided on the hosted review page. Pass requestedSchema (a JSON Schema in the MCP elicitation requestedSchema subset — flat object of strings/numbers/booleans/enums) to define the editable Proposed fields; each property's default is its initial proposed value (you compute it — e.g. take Current if present else Source). Pass columns to name the Source column(s) and the Current column, and fields to supply each property's Source value(s) and Current value. The reviewer edits proposed values, chooses which fields to include, and submits; the result (via elicit_result) carries decision (submitted|declined) and, on submit, values (included fields only). MUST NOT be used to request secrets or credentials.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNoPer-property read-only cell values, keyed by requestedSchema property name: { <property>: { sources: { <sourceKey>: value }, current: value, include?: boolean } }. `include: false` starts the field unchecked.
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.
columnsYesNames the read-only columns of the diff grid.
contextNoOptional identity/context passthrough echoed back verbatim in elicit_result — NOT shown to the reviewer unless `displayTemplate` renders it.
messageYesThe prompt shown to the reviewer above the diff grid — say what change is proposed and why.
displayTemplateNoOptional LiquidJS template rendered above the grid. `context` is exposed under the `context` key (e.g. {{ context.recordId }}). Without it, `context` is not displayed.
requestedSchemaYesJSON Schema (MCP elicitation requestedSchema subset — flat object of string / number / boolean / enum properties) defining the editable Proposed fields; each property's `default` is its initial proposed value.
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 / columns / description
      Added value: +"Names the read-only columns of the diff grid."
    • addedInput schema / properties / columns / properties / current / properties / label / description
      Added value: +"Header of the read-only Current column."
    • addedInput schema / properties / columns / properties / sources / description
      Added value: +"The read-only Source column(s), in display order."
    • addedInput schema / properties / columns / properties / sources / items / properties / key / description
      Added value: +"Unique key referenced by `fields.<property>.sources`."
    • addedInput schema / properties / columns / properties / sources / items / properties / label / description
      Added value: +"Column header shown to the reviewer."
    • addedInput schema / properties / context / description
      Added value: +"Optional identity/context passthrough echoed back verbatim in elicit_result — NOT shown to the reviewer unless `displayTemplate` renders it."
    • 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 / fields / description
      Added value: +"Per-property read-only cell values, keyed by requestedSchema property name: { <property>: { sources: { <sourceKey>: value }, current: value, include?: boolean } }. `include: false` starts the field unchecked."
    • 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 above the diff grid — say what change is proposed and why."
    • addedInput schema / properties / requestedSchema / description
      Added value: +"JSON Schema (MCP elicitation requestedSchema subset — flat object of string / number / boolean / enum properties) defining the editable Proposed fields; each property's `default` is its initial proposed value."
    • 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.8/5.0
Behavior5/5

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

Beyond the annotations (idempotentHint false, destructiveHint false), the description discloses substantial behavioral details: it is async, returns a pending request decided on a hosted review page, lets the reviewer edit proposed values and choose which fields to include, and returns a specific result shape via elicit_result. It also explains how default proposed values are computed, which is non-obvious and valuable.

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?

The description is dense but every clause earns its place, starting with the core purpose and moving through async behavior, parameter usage, result format, and a critical safety constraint. It is front-loaded and readable despite covering up to eight parameters and a complex diff-grid interaction, with no filler or tautology.

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 tool with nested objects, eight parameters, and an output schema, the description captures everything an agent needs: what request to construct, how defaults and column mappings work, what the reviewer interaction looks like, how the result is received, and what must never be passed. It is complete without redundantly restating the output schema.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds meaning beyond the raw schema: it explicitly explains the role of requestedSchema defaults, how to fill Source/Current values with columns and fields, that context is echoed back but not shown unless displayTemplate renders it, and that expiresInSeconds is clamped. This guidance walks an agent through composing a correct call rather than merely restating parameter names.

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 uses a specific verb and resource: 'Ask a human to review, edit, and selectively approve a proposed record create-or-update' and identifies the distinguishing diff-grid interface. It clearly indicates what the tool produces (a pending review request) and sets it apart from generic approval tools, despite sharing an 'elicit_' prefix.

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 establishes clear context for when to use the tool: any time a human must review and selectively approve a proposed record change. It also gives a hard exclusion ('MUST NOT be used to request secrets or credentials') and compares its async behavior to elicit_approval, but it never explicitly names a sibling tool to prefer for other scenarios, such as simple approvals or confirmations.

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