Elicitly Pro

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

Annotations cover only openWorld/idempotent/destructive hints, and the description adds substantially more: returns immediately with a pending request decided later, the hosted review page flow, the MCP spec prohibition on requesting secrets/credentials in form mode, and the fact that `context` is not merged into or used to pre-fill form fields. That last point is exactly the kind of behavioral trap an agent would otherwise get wrong.

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

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

It is long, but front-loaded with the async-vs-sync decision and organized into clearly marked modes, so no sentence is filler. It could be tightened slightly (the MCP-version parenthetical and repeated subset restatements), but the density is justified by the behavioral traps it prevents.

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

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

With an output schema present, return values need not be explained, and the description still covers the async lifecycle, both modes, the schema subset restriction, the sensitive-data prohibition, and the alternative tools. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description materially enriches several params: `context` is echoed verbatim and rendered as raw JSON unless `displayTemplate` is given, `displayTemplate` is a LiquidJS template with `context` exposed under the `context` key, and `requestedSchema` is constrained to the flat MCP subset with defaults seeding the form. `labels` and `expiresInSeconds` are left entirely to the schema, which is the only small gap.

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

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

Opens with a specific verb+resource ('Request human approval') and immediately scopes it against siblings by naming elicit_await, elicit_result, and elicit_form with the condition that selects each. An agent can tell this apart from the other twelve elicit_* tools without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: async mode blocks via elicit_await and fetches via elicit_result, while synchronous in-session forms belong to elicit_form. It also states the precondition that at least one of `context`/`requestedSchema` is required and when to pick each mode (including passing both together).

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the real behavioral load and does: it discloses that the call blocks, the exact terminal conditions (submitted/declined/canceled/expired/window close), and that `pending` is not a failure but a window expiry requiring a re-call. That is precisely the non-obvious context an agent needs to avoid mis-handling a timeout as an error.

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

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

Four dense sentences, zero filler, and the core blocking semantics plus the `pending`-means-retry rule are front-loaded before the timeout tuning advice. Every sentence earns its place.

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

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

With an output schema present, the description needn't enumerate return values, and it covers blocking, retry, and timeout interaction well. The one missing link is what to do after a `submitted` status — presumably `elicit_result` — which would complete the workflow chain across siblings.

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

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

Schema coverage is 100%, so both parameters are already documented, including the 50-second default and the "can only shorten, never extend" rule. The description restates the host-timeout rationale but adds no syntax or edge-case detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ("Long-poll for a decision on a pending elicitation") and immediately names the sibling it replaces ("Prefer this over polling `elicit_status` in a loop"). An agent can distinguish it from elicit_status, elicit_result, and elicit_cancel 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it over the alternative ("Prefer this over polling `elicit_status` in a loop") and gives a concrete condition for choosing `maxWaitSeconds` ("If your host or gateway times out tool calls sooner than the server's window"). It also tells the agent what to do on a `pending` return, closing the retry loop.

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

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

Annotations only say destructiveHint=true, idempotentHint=false, openWorldHint=false. The description adds substantial context beyond that: the resulting terminal state, that the review page stops accepting decisions, that pending `elicit_await` calls wake, that `elicit_result` has no outcome, the error conditions, and the concurrent-decision race behavior. This is exceptional disclosure for a mutation tool.

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

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

Front-loaded with verb+resource, then consequence, then edge cases and race semantics. Every sentence carries distinct operational information with no restatement of the name or title.

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

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

An output schema exists so return values needn't be spelled out, yet the description still tells the agent what happens downstream (elicit_result has no outcome). For a one-parameter mutation tool, nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so `elicitationId` is already fully documented, and the baseline is 3. The phrase 'you created' hints at an ownership constraint not stated in the schema, but no format, length, or lookup guidance is added, so this remains at the schema-driven baseline.

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

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

States a specific verb and resource ('Withdraw a pending elicitation you created') and immediately disambiguates the resulting terminal status from the sibling concepts `declined` and `expired`. An agent can distinguish this from elicit_status, elicit_result, or elicit_await purely from the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear when-to-use motivation ('the plan changed or the request is superseded') and explicit when-not conditions ('Errors if the request was already decided or has expired'). It stops short of routing the agent to a sibling tool for the alternative cases, so it is clear context rather than full alternative-selection guidance.

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

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.

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.

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.

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.

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.

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.

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them: the CDN allowlist (cdn.jsdelivr.net plus org-allowed origins), that disallowed origins are blocked and listed in the result notes, HTML-escaping of {{ context.* }}, JavaScript-style truthiness, Tailwind/DaisyUI support, data-theme theme following, and the fact that rendered HTML is never returned to the model. This is unusually rich operational disclosure.

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

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

The core purpose and the sibling routing are front-loaded in the first sentence, which is the right call. The remainder is a dense single paragraph of em-dash and parenthetical asides; nearly every clause carries usable operational detail, but the block is harder to scan than a short bulleted constraint list would be.

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

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

For a rendering tool with an output schema, the description still closes the important gaps: it states the rendered HTML is not returned to the model, what the result does report, how interpolation is escaped, and what resource-loading will silently fail. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is already 100%, so the schema documents all four parameters, but the description adds real meaning on top: data: URIs must be passed in context rather than the template and the 64 KB vs 32 KB budget explains why. That's a non-obvious interaction between two parameters that the schema alone does not convey.

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

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

Names a specific verb and resource (render LiquidJS template + JSON context as HTML in the conversation) and immediately distinguishes itself from the decision-collecting siblings elicit_approval, elicit_selection, and elicit_confirm. An agent can tell this is a display-only tool 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when ('tables, reports, and summaries the user should scan') and an explicit when-not with named alternatives ('it does not collect a decision — use elicit_approval, elicit_selection, or elicit_confirm'). Routing between this tool and its closest siblings is fully specified.

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

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

Annotations only say openWorldHint=false and destructiveHint=false; the description adds the material behavioral facts beyond them — that probeElicitation fires a live round-trip with a possible user dialog, that share: true enqueues the report to a public evidence queue, exactly what is stored, and that no elicitation payloads or conversation content leave. This is exactly the extra context annotations cannot carry.

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

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

Purpose and the safety/privacy caveats are front-loaded, and each sentence carries distinct information. It is dense and the longer sentences (share clause) could be split, but nothing is redundant padding.

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

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

An output schema exists, so return structure needn't be documented, and the description still explains the passive-vs-probe modes, the sharing side effect, and data handling. An agent has everything needed to decide whether and how to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds the interaction between parameters: probeElicitation's default-false passive behavior, and the pairing of share: true with productName/productVersion/notes that the report cannot self-detect. It slightly exceeds the schema's per-field text by explaining why those fields exist and what the result carries (shared: true|false).

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

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

The description states a specific verb and resource — diagnosing whether the connected host actually supports elicitation — and explicitly frames it against the sibling call targets (elicit_form/elicit_confirm). An agent can distinguish this diagnostic tool from the other elicit_* siblings 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use triggers: deciding whether to call elicit_form/elicit_confirm, explaining why a prompt did or didn't appear, or contributing a capability fingerprint. The alternative path (turn on probeElicitation vs the default passive report) is spelled out with the trade-off.

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

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

Annotations only cover openWorld/destructive hints, so the description carries the rest. It discloses the return shape ('raw {action, content}') and a notable behavioral constraint (MUST NOT be used to request secrets or credentials). It doesn't cover auth or what happens on timeout failure.

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

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

Two sentences, zero waste, with the core capability front-loaded and the routing/prohibition clauses after it. Every clause earns its place.

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

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

An output schema exists, so return values need not be elaborated; the description still notes the raw return shape. Purpose, the primary alternative, and the sensitive-data prohibition are all present, which is sufficient for a 3-param tool with rich schema coverage.

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

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

The schema already documents all three parameters at 100% coverage, including the timeout default and clamp range and the requestedSchema subset restriction. The description adds no format or syntax detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb+resource ('Trigger a form elicitation with a caller-supplied JSON schema') and names the sibling it is not for ('For a plain OK/Cancel question, prefer elicit_confirm'). An agent can distinguish it from elicit_confirm without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the common OK/Cancel case to elicit_confirm and states a hard exclusion (no secrets/credentials). It does not differentiate against the other form-like siblings (elicit_selection, elicit_proposal, elicit_display), 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.

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's added value is the pagination behavior and permission constraint: org scope is admin-only, and passing back `asOf` keeps the window stable as new requests arrive. That goes beyond what annotations declare.

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

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

Three sentences, front-loaded with purpose, ordering, and pagination before the return shape and the page-computation tip. Dense but every sentence carries information; no filler.

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

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

Covers pagination semantics, stability across pages, permission gating for org scope, and the returned fields — more than an output schema would require. Nothing material for correct invocation is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description adds real meaning by tying `asOf` to cross-page stability and showing how `total` yields the last page via ceil(total/pageSize). It largely mirrors the schema text for `scope`, but the pagination recipe is genuinely additive.

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

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

States a specific verb+resource ('List your past elicitations') with scope and ordering ('newest first'), which cleanly separates it from the sibling action tools (elicit_approval, elicit_await, etc.). An agent can identify this as the read/history tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the `scope` choice ('me' = your own; 'org' = whole organization, admins only) and when to reuse `asOf` across pages. It gives clear context but does not explicitly name an alternative tool or state when-not-to-use this one.

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

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

Annotations already declare readOnlyHint=true, so no mutation concern. The description adds meaningful context beyond the annotation by specifying that it echoes the message as 'pong: <message>' and that it requires an authenticated session, which helps the agent understand expected behavior.

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

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

A single sentence that front-loads the purpose ('Connectivity check'), states the resource, and explains the returned output. Every word earns its place with zero redundancy.

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

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

For a tool with one optional parameter and no output schema, the description is complete: it conveys purpose, behavior, the authenticated-session requirement, and the exact return format. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, with the 'message' parameter fully described as 'Text to echo back (default "ping")'. The description reinforces this by showing the output format, but does not add substantial new parameter-level meaning beyond the schema.

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

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

The description states a specific verb ('Connectivity check') and resource ('hosted Elicitly server'), and explains the exact echo behavior. This clearly distinguishes it from sibling elicit_* tools, which are all task-oriented operations rather than a ping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies the tool is for verifying connectivity and that it operates over an authenticated session. It does not explicitly list when-not-to-use it, but the dedicated ping nature makes the usage context unambiguous among the siblings.

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

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.

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.

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.

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.

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.

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.

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

Annotations cover the safety profile (idempotentHint=true, destructiveHint=false), and the description goes further by disclosing lifecycle error states (pending, expired, canceled) and read-repeatability semantics. It also explains how the returned formSubmission varies by the originating tool, which no annotation conveys.

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

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

Front-loaded with purpose, then preconditions, then return shape — a sensible order with no filler sentences. The long parentheticals make it dense to read, but every clause carries actionable information rather than repetition.

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

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

An output schema exists, yet the description still usefully explains the per-tool variation in formSubmission, which the schema alone would not make obvious. Prerequisites, failure modes, and return shape are all covered for this single-parameter tool.

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

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

Schema description coverage is 100% and the single parameter's provenance is already documented in the schema ('returned by the creating tool'). The description's parenthetical listing of calling tools adds marginal reinforcement but no new syntax or format detail, so baseline 3 applies.

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

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

States a specific verb+resource ('fetch the outcome of a decided request') and immediately distinguishes itself from siblings by naming elicit_status and elicit_await as the prerequisite steps. An agent can tell it apart from elicit_cancel and the creating tools 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the required ordering ('poll elicit_status or block on elicit_await first') and the three conditions under which it fails: still pending, expired undecided, or canceled via elicit_cancel. It also clarifies that repeat reads are permitted, leaving nothing to inference.

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

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

Annotations cover only safety/hints (openWorldHint=false, destructiveHint=false, idempotentHint=false), so the description carries the workflow burden and does so well: it discloses the async pending-request model, that the decision happens on the hosted review page, and that selected ids return via elicit_result as `selectedIds`. It does not cover expiry or cancellation behavior, but the core interaction model is explicit.

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

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

Front-loaded with purpose, then the async contract, then rendering/selection semantics, in roughly four dense sentences. Nearly every clause earns its place, though the rendering sentence and the single/multi-select sentence could be compressed into one without loss.

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

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

With an output schema present, return values need not be described, and the description still adds the essential lifecycle (where the decision happens, how the result is fetched) plus the default selection mode for an 11-parameter tool with nested objects. Remaining gaps (expiry, behavior on decline) are minor rather than blocking.

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

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 earns extra by clarifying cross-parameter default semantics — single-select by default with `maxSelections` as the switch to multi-select — and by explaining how `css` and Liquid templates shape the option table. Detail on individual template parameters stays in the schema.

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

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

The first sentence gives a specific verb and resource ('ask a human to choose one or more options from a caller-supplied list') plus concrete use cases (disambiguation, record matching, picking work items). It also distinguishes itself from siblings by name, framing the async flow relative to 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Concrete use cases and a clear routing signal to elicit_result for retrieving the answer, plus the async framing that parallels elicit_approval. It stops short of stating when NOT to use it (e.g. vs elicit_confirm or elicit_form), so an agent must infer the boundary from the selection-shaped framing.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the genuinely important behavioral traits beyond that — non-blocking, repeatable, and 'never consumes the result' (contrasting with elicit_result, which does). It also enumerates the possible status values the caller will observe.

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

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

A single dense sentence that front-loads the core behavior, then the return shape, then the alternative tools. No filler, no repetition of the title.

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

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

Read-only safety is covered by annotations, the return value is enumerated inline (and an output schema exists), and the sibling routing is spelled out. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100% and the single parameter's origin is already documented in the schema ('returned by the creating tool'). The description's phrasing 'an elicitation you created' adds a mild ownership constraint but nothing about id format or lookup behavior. Baseline 3 applies when the schema carries the parameter detail.

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

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

States a specific verb and resource ('non-blocking status check for an elicitation') and immediately differentiates itself from two named siblings, elicit_await and elicit_result. An agent can pick this tool 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: use this for non-blocking checks, elicit_await to block on a decision, elicit_result to fetch the outcome. It also implicitly scopes usage to elicitations the caller created.

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