Skip to main content
Glama
Sign In

Elicitly Pro

by ai.elicitly
OverviewDiscussionsAdmin

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, formSubmission (included fields only). MUST NOT be used to request secrets or credentials.

Input 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

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. 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"
+}
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (which only declare non-destructive, non-idempotent, closed-world), the description discloses the async lifecycle, that a pending request is decided on a hosted page, the reviewer's edit/select/submit flow, and the exact result payload (`decision` = submitted|declined, `formSubmission` = included fields only). This is substantial behavioral context the annotations do not carry.

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?

Purpose and mechanism are front-loaded in the first sentence, and most subsequent sentences carry real payload (default computation, result shape, the secrets exclusion). It is dense and slightly long, but nearly every clause earns its place for a tool this complex.

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 an 8-parameter async tool with nested objects and an output schema, the description covers the async model, the grid model, the key parameter semantics, and the result path to elicit_result. Return values are not over-explained (output schema exists), and the secrets prohibition closes the main misuse risk.

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 would be 3, but the description adds genuine semantics: it explains that `requestedSchema` defines the editable Proposed fields and that each property's `default` is the initial value the caller must compute (Current if present else Source), and it clarifies the roles of `columns` and `fields` in populating the grid. This is more than the schema restates.

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?

States a specific verb and resource ('Ask a human to review, edit, and selectively approve a proposed record create-or-update') and pins the mechanism ('shown as a diff grid: read-only Source / Current columns, editable Proposed column'). This makes it immediately distinguishable from elicit_approval and elicit_form without opening any schema.

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?

Gives clear usage context ('Async like elicit_approval: returns a pending request decided on the hosted review page') and names the follow-up sibling (elicit_result), plus an explicit exclusion ('MUST NOT be used to request secrets or credentials'). It does not directly state when to choose this over sibling form/selection tools, so it stops short of full routing 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 toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources