Elicitly Pro

List past elicitations

elicit_history

Read-only

List your past elicitations, newest first, paginated with jump-to-page. scope 'me' = your own requests; 'org' = the whole organization (admins only). Returns { items, page, pageSize, asOf, total, scope } — total lets you compute the last page (ceil(total/pageSize)); pass the returned asOf back on later pages to keep the window stable while new requests arrive.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`asOf`	No	Snapshot anchor from a previous page's result — pass it back to keep pagination stable while new requests arrive. Omit on the first page.
`page`	No	1-based page number to fetch.
`scope`	No	'me' = your own requests; 'org' = the whole organization (admins only).	me
`pageSize`	No	Items per page (1-100).

Output Schema

TableJSON Schema

Name	Required	Description
`asOf`	Yes	The snapshot anchor this page was computed at — pass it back on later pages to keep the window stable while new requests arrive.
`page`	Yes	The 1-based page that was served.
`items`	Yes	The requested page of elicitations, newest first.
`scope`	Yes	The scope that was served.
`total`	Yes	Total matching requests — the last page is ceil(total / pageSize).
`pageSize`	Yes	Items per page that was applied.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed5 schema fields changedSep 5, 2026

addedInput schema / properties / asOf / description

Added value: +"Snapshot anchor from a previous page's result — pass it back to keep pagination stable while new requests arrive. Omit on the first page."

addedInput schema / properties / page / description
```
Added value: +"1-based page number to fetch."
```
addedInput schema / properties / pageSize / description
```
Added value: +"Items per page (1-100)."
```

addedInput schema / properties / scope / description

Added value: +"'me' = your own requests; 'org' = the whole organization (admins only)."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "asOf": {
+      "description": "The snapshot anchor this page was computed at — pass it back on later pages to keep the window stable while new requests arrive.",
+      "type": "string"
+    },
+    "items": {
+      "description": "The requested page of elicitations, newest first.",
+      "items": {
+        "additionalProperties": {},
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "page": {
+      "description": "The 1-based page that was served.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "pageSize": {
+      "description": "Items per page that was applied.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "scope": {
+      "description": "The scope that was served.",
+      "enum": [
+        "me",
+        "org"
+      ],
+      "type": "string"
+    },
+    "total": {
+      "description": "Total matching requests — the last page is ceil(total / pageSize).",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "items",
+    "page",
+    "pageSize",
+    "asOf",
+    "total",
+    "scope"
+  ],
+  "type": "object"
+}

First observedSep 4, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already mark this read-only and closed-world, and the description adds valuable behavior: newest-first ordering, the exact return shape, the meaning of total for computing the last page, and the asOf snapshot mechanism for stable pagination. These details go beyond the annotations without contradicting them.

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 compact and front-loaded with the core purpose, then covers scope, then the return contract and pagination behavior. Every sentence earns its place and there is no filler.

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 read-only listing tool with four optional parameters, full schema coverage, annotations, and an output schema, the description is complete: it covers scope permissions, ordering, pagination, return fields, and the asOf mechanism for a stable window. An agent has enough information to invoke it correctly.

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%, so the schema already documents all parameters. The description repeats scope and asOf semantics but does not add meaningful new parameter-level guidance beyond the schema; the total-last-page note is return-value guidance rather than parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear verb and resource: 'List your past elicitations', and adds ordering and pagination context. It does not explicitly differentiate from sibling tools like elicit_status or elicit_result, so it falls short of a top score that names alternatives.

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?

It gives clear operational context: newest-first ordering, pagination, admin-only org scope, and how to keep pagination stable with asOf. It does not explicitly recommend when to use this tool versus another sibling or state exclusions.

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?