Skip to main content
Glama
Sign In

Elicitly Pro

by ai.elicitly
OverviewDiscussionsAdmin

Ask the user to confirm (OK/Cancel)

elicit_confirm

Ask the user an OK/Cancel confirmation via elicitation (convenience wrapper over elicit_form), modeled on JavaScript's confirm(). Use this for a single yes/no question; use elicit_form to collect arbitrary fields. Returns three-state {confirmed}: true = proceed, false = a human explicitly said no, null = no answer was obtained (reason: "dismissed" | "error") — ask again later.

Input Schema

NameRequiredDescriptionDefault
labelsNoRelabel or localize the OK/Cancel buttons. Each label is trimmed, 1-40 characters; unknown keys are rejected. Button placement and styling stay fixed.
messageYesThe yes/no question shown to the user in the host's elicitation dialog.
timeoutSecondsNoHow long to wait for the answer, in seconds (default 300, clamped 60-3600).

Output Schema

NameRequiredDescriptionDefault
reasonNoPresent only when confirmed is null: "dismissed" = the elicitation was closed unanswered (including timeout), "error" = it failed.
confirmedYestrue = the user chose OK; false = an explicit no (Cancel choice or declined elicitation); null = no answer was obtained.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / additionalProperties
      Previous value: -falseNew value: +{}
  2. Changed6 schema fields changed
    • addedInput schema / properties / labels / description
      Added value: +"Relabel or localize the OK/Cancel buttons. Each label is trimmed, 1-40 characters; unknown keys are rejected. Button placement and styling stay fixed."
    • addedInput schema / properties / labels / properties / cancel / description
      Added value: +"Replacement label for the Cancel button (e.g. \"Cancelar\")."
    • addedInput schema / properties / labels / properties / ok / description
      Added value: +"Replacement label for the OK button (e.g. \"Aceptar\")."
    • addedInput schema / properties / message / description
      Added value: +"The yes/no question shown to the user in the host's elicitation dialog."
    • addedInput schema / properties / timeoutSeconds / description
      Added value: +"How long to wait for the answer, in seconds (default 300, clamped 60-3600)."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "confirmed": {
+      "description": "true = the user chose OK; false = an explicit no (Cancel choice or declined elicitation); null = no answer was obtained.",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "reason": {
+      "description": "Present only when confirmed is null: \"dismissed\" = the elicitation was closed unanswered (including timeout), \"error\" = it failed.",
+      "enum": [
+        "dismissed",
+        "error"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "confirmed"
+  ],
+  "type": "object"
+}
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations are thin (only openWorldHint/destructiveHint=false), and the description compensates by disclosing the three-state return contract and the dismissied/error reason values plus the retry advice ('ask again later') — genuinely useful behavior beyond the annotations. It stops short of 5 because it omits what happens on timeout expiry and any permission/dialog-context caveats.

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?

Three tight sentences, front-loaded with purpose, then routing, then return contract. The return-value sentence is partly redundant given an output schema exists, but it carries the non-obvious tri-state semantics, so it mostly earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, sibling routing, and the return/retry semantics an agent needs, and an output schema exists to carry the response shape. The remaining gap is disambiguation from the closest sibling, elicit_approval, which the description never addresses.

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

Parameters3/5

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

Schema description coverage is 100% and every parameter (message, labels.ok/cancel, timeoutSeconds) is already documented in the schema, including trimming/clamping rules. The description adds no additional parameter semantics, so the baseline 3 applies.

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?

Names a specific verb+resource ('Ask the user an OK/Cancel confirmation') and adds the implementation identity (convenience wrapper over elicit_form, modeled on confirm()), which immediately separates it from the other elicit_* siblings.

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?

Explicitly states the selecting condition ('single yes/no question') and the alternative ('use elicit_form to collect arbitrary fields'). However, with 13 siblings including the very close elicit_approval and elicit_selection, the routing is not exhaustive — it never says when this should lose to elicit_approval, which an agent must disambiguate.

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
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources