Elicitly Pro

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

The annotations are minimal (openWorldHint, idempotentHint, destructiveHint all false), so the description carries the burden of behavioral disclosure. It thoroughly explains the async 'returns immediately with a pending request' behavior, the differences between json and form modes, the fact that context is read-only and echoed back verbatim, that context does not pre-fill form fields, and that defaults seed the form. It also discloses the expiration behavior in the schema. It doesn't explicitly discuss rate limits or failure modes, but the described behaviors are substantial and beyond what annotations provide.

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 description is dense and information-rich, but it is quite long and packs many details into one paragraph. It is front-loaded with the core purpose and the key distinguishing sibling reference, which is good. However, the form-mode restrictions and mode-by-mode explanations could be structured more cleanly. It earns a 3 because while every sentence carries information, the wall-of-text format makes it harder for an agent to quickly parse the key decision points.

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 complex 6-parameter tool with nested objects and an output schema, the description is remarkably complete. It covers the async behavior, the two modes, parameter relationships, constraints from the MCP spec, security limitations (no secrets in form mode), and points to sibling tools for follow-up operations. An agent would have all the information needed to select and invoke this tool 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 description coverage is 100%, so the schema already documents all 6 parameters. The description adds meaningful semantic value by explaining the relationship between context and displayTemplate, the implications of requestedSchema (flat object, defaults seeding the form), and the exact behavior of context in form mode (NOT merged into form fields). It also clarifies the required-ness of context/requestedSchema ('at least one is required') beyond what the schema shows. This goes beyond just repeating schema descriptions.

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 clearly states the tool's purpose: 'Request human approval before proceeding.' It uses a specific verb (request) and resource (human approval), and immediately distinguishes it from sibling tools like elicit_await, elicit_result, and elicit_form. It comprehensively describes the two operating modes (json mode and form mode), making it unambiguous what this tool does and how it differs from related tools.

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 explicitly provides usage guidance: it states when to use this tool (before proceeding with an operation needing human approval), describes the async vs sync distinction, and explicitly names alternatives (`elicit_await` for blocking, `elicit_result` for fetching outcome, `elicit_form` for synchronous in-session form). It also gives a clear constraint: 'form mode MUST NOT be used to request secrets, credentials, or other sensitive information.' This is exemplary usage 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?

The description discloses the blocking long-poll behavior, the polling-window close condition, and the meaning of each returned status. Even with `readOnlyHint: true`, it adds valuable behavioral detail beyond the annotation by explaining what the caller should do on a `pending` result.

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 description is three sentences with no filler. It front-loads the core behavior, immediately states the return shape, and closes with a practical usage recommendation.

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 one-parameter tool with an output schema and read-only annotation, the description is complete: it covers the blocking semantics, all possible statuses, timeout behavior, and the recommended alternative. Nothing essential is missing for an agent to select and 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?

The input schema already covers the single parameter `elicitationId` with a description that explains where to obtain it. The tool description adds no additional parameter-level detail, but none is needed given 100% schema coverage.

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 clearly states a specific verb ('long-poll') and resource ('decision on a pending elicitation'), and enumerates the possible terminal statuses. It also differentiates itself from the sibling tool `elicit_status` by explicitly recommending against polling in a loop.

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 explicitly says when to use the tool: for waiting on a pending elicitation rather than polling `elicit_status` in a loop. It also explains that a `pending` return means the polling window elapsed and the caller should invoke the tool again, giving clear operational 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?

The description goes far beyond the annotations, detailing the terminal `canceled` status, the shutdown of further decisions, waking of pending `elicit_await` calls, the absence of an `elicit_result` outcome, error conditions, and the race behavior. This is rich, accurate behavioral context that an agent needs.

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 description is dense but every sentence carries meaningful operational information. The primary purpose and rationale come first, followed by consequences, edge cases, and concurrency semantics. No filler or 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?

For a destructive, non-idempotent operation, the description fully covers what happens, when it fails, how it interacts with related tools, and concurrency behavior. An output schema exists, so return-value details are already structured. Nothing essential 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?

The schema fully documents the single parameter, including its type, required status, and source. The description adds some context by implying the elicitation must be one the user created, but it does not materially enrich the already complete parameter documentation. Baseline 3 is appropriate.

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 ('Withdraw a pending elicitation you created') and a clear resource. It distinguishes the action from related statuses like `declined` and `expired`, and positions cancellation relative to other elicitation tools without ambiguity.

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 clearly describes when to use the tool: when a plan changed or the request is superseded, and only for a pending elicitation the user created. It also implicitly says when not to use it by noting it errors if already decided or expired. It does not explicitly name an alternative tool, but that is not necessary given the unique cancel semantics.

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, the description discloses the three-state return contract, including what true, false, and null mean, plus the possible reasons for null ('dismissed' | 'error'). It also notes the tool is a convenience wrapper, giving the agent a clear mental model of 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?

The description is compact and well-structured: purpose first, usage guidance second, return semantics third. Every sentence contributes meaningful information with no 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?

With an output schema present and full parameter documentation in the input schema, the description covers the remaining contextual needs: what the tool is for, when to choose it, and how to interpret ambiguous results. Nothing essential 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%, so the schema fully documents message, labels, and timeoutSeconds. The description does not add parameter-level detail beyond that, but the baseline of 3 is appropriate because the schema carries the load.

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 action ('Ask the user an OK/Cancel confirmation'), names the protocol it models (JavaScript confirm), and identifies itself as a convenience wrapper over elicit_form. It clearly distinguishes itself from siblings by scoping to a single yes/no question rather than arbitrary field collection.

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 explicitly states when to use this tool: 'Use this for a single yes/no question; use elicit_form to collect arbitrary fields.' It also provides guidance for handling the null result: 'ask again later.' This is direct, actionable 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 are minimal (openWorldHint false, destructiveHint false, no readOnlyHint), so the description carries the transparency burden and meets it thoroughly: it discloses the user-visible dialog side effect of probeElicitation, the external write when share: true (public evidence queue), a privacy guarantee ('no elicitation payloads or conversation content'), and an intrinsic limitation (the report cannot see productName/version from inside). The public-queue write sits slightly at odds with a hard closed-world reading of openWorldHint: false, but it's an explicit opt-in, so not a contradiction.

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 the purpose sentence and every sentence carries load — handshake echo, derived booleans, deprecations, probe behavior, privacy, and the share flow. But it is one dense, jargon-laden run-on paragraph (SEP-2577, Elicitly-derived booleans, probes.elicitationForm) that would scan far better split into two or three structured sentences.

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?

Given an output schema exists and all five parameters are documented, the description covers the essential operational context: what the report contains, when a dialog appears, what gets stored externally, what doesn't, and where background material lives (linked docs). Minor gap: it doesn't say how the derived booleans should be interpreted or what practical consequences the deprecations flag carry, leaving that to the output schema.

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% and each parameter's schema description is already rich (share's storage semantics, probeElicitation's dialog warning, productName's example). The main description largely restates that content; the only genuinely new tidbit is that the result carries shared: true|false. Baseline 3 applies when the schema does the heavy lifting.

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 pair: 'Report the connected host's elicitation/sampling/roots support.' That single sentence makes the diagnostic purpose unambiguous and immediately sets it apart from the eleven sibling tools, which manipulate an elicitation flow (approve, cancel, confirm, form) rather than inspect host capabilities.

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?

No explicit when-to-use or when-not-to-use guidance relative to siblings; the agent must infer from the 'report' verb that this is the diagnostic tool. Within the tool it does clarify mode choice — passive by default vs the live probeElicitation round-trip and when share: true is appropriate — but it never names an alternative ('for liveness use elicit_ping') or an exclusion condition.

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 minimal (openWorldHint false, destructiveHint false), so the description carries some responsibility for behavioral disclosure. It adds useful context about the return shape ('raw {action, content}') and imposes a security constraint against sensitive data. It does not describe cancellation or error behavior, but the output schema likely covers the return contract.

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 with no filler. The primary purpose is first, the sibling alternative is second, and the security prohibition is last. Every sentence earns its place and is tightly scoped.

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?

Given the three-parameter schema, the output schema, and the annotations, the description gives enough for an agent to call the tool correctly: purpose, return shape, alternative tool, and a critical security constraint. A minor gap is that it does not explain what happens if the user cancels or closes the form, but the output schema likely conveys that via the {action, content} structure.

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 schema already documents message, timeoutSeconds, and requestedSchema thoroughly. The description says 'caller-supplied JSON schema' and mentions returning raw {action, content}, but these mainly restate what the input schema and output schema already express. This matches the baseline 3: the description adds no substantial 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 ('Trigger'), the resource ('a form elicitation'), and the key mechanism (caller-supplied JSON schema), and it mentions the return value ('raw {action, content}'). It also distinguishes itself from elicit_confirm in the same senence, so an agent can identify the correct 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?

It gives an explicit alternative: 'For a plain OK/Cancel question, prefer elicit_confirm.' It also provides a clear exclusion boundary: 'MUST NOT be used to request secrets, credentials, or other sensitive information.' This gives the agent concrete when-to-use and when-not-to-use guidance beyond the generic title.

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 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.

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.

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.

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.

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.

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.

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 (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.

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.

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.

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.

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.

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.

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

Annotations already mark the tool as idempotent and non-destructive, but the description adds valuable behavioral context: error conditions, repeatable-read reassurance, and the exact return shape including per-tool overlays. No contradiction with annotations.

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 front-loads the core purpose, then efficiently packs lifecycle conditions, error semantics, and return format without filler. 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?

For a single-parameter tool with an output schema, the description fully covers preconditions, error states, idempotency, and the return shape with per-tool overlays. An agent has everything needed 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% and the schema already clearly describes elicitationId as returned by the creating tool. The description adds no additional parameter meaning beyond the schema, so the baseline of 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?

The description states a specific verb and resource: 'Fetch the outcome of a decided request'. It also distinguishes itself from siblings by explicitly referencing elicit_status, elicit_await, and elicit_cancel, making its role in the elicitation lifecycle clear.

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 explicitly instructs the agent to poll elicit_status or block on elicit_await first, and explains when this tool errors: while pending, after expiring undecided, or after cancellation. This gives clear when-to-use and when-not-to-use guidance relative to sibling tools.

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 openWorldHint=false, idempotentHint=false, destructiveHint=false. The description adds important behavioral context beyond annotations: the operation is asynchronous, returns a pending request, is decided on the hosted review page, and returns selected IDs through elicit_result. Multi-select defaults are also disclosed. This is solid non-obvious behavior information.

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 dense sentences front-load the purpose, then flow, then customization and selection defaults. Every sentence adds operational value without repeating schema details. The structure is efficient and scannable for an agent.

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?

The tool has 11 parameters and nested objects, but the schema carries detailed per-parameter descriptions and an output schema exists. The description provides the missing operational context: async behavior, result retrieval path, default selection mode, and template/CSS customization. Nothing essential for correct invocation is left out.

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 adds extra semantic value by noting that options render as table rows, that Liquid templates and CSS can customize rendering, and that maxSelections raises single-select to multi-select. It also clarifies the meaning of option IDs as what comes back in selectedIds.

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?

Description opens with a specific verb and resource: 'Ask a human to choose one or more options from a caller-supplied list', followed by concrete use cases (disambiguation, record matching, picking work items). This clearly identifies what the tool does and distinguishes it from siblings like 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?

The description gives clear context for when to use this tool via concrete use cases and explains the async flow ('Async like elicit_approval... decisions come back via elicit_result'). It doesn't explicitly say when not to use alternatives, but the context is strong enough for an agent to route correctly.

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 mark the tool as readOnlyHint=true, and the description adds important behavioral context: it is non-blocking, never consumes the result, and returns only the status, not the full outcome. This goes beyond the annotation by explaining the exact side-effect-free contract and the scope 'for an elicitation you created'.

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 with no wasted words. The core purpose and status values are front-loaded, and the alternative-tool guidance is placed in the second sentence. 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?

The description fully covers what an agent needs: the action, the exact return shape, the statuses, the non-consuming behavior, and the routing to sibling tools. An output schema exists, so return-value detail need not be repeated, and nothing essential 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?

The schema has 100% description coverage for its single required parameter, and the schema already explains that `elicitationId` is returned by the creating tool. The description adds no additional parameter-level semantics beyond reinforcing 'you created', so the baseline of 3 is appropriate.

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 ('status check'), a clear resource ('elicitation'), and an explicit outcome: returns `{ status }` with all six possible status values. It also differentiates itself from sibling tools by naming `elicit_await` and `elicit_result` as alternatives for other behaviors, so an agent can distinguish it without opening schemas.

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 gives explicit guidance on when to use this tool: it is non-blocking, read-only, and repeatable, and it says to use `elicit_await` to block and `elicit_result` to fetch the outcome. This directly tells the agent which sibling to select for adjacent use cases, leaving no ambiguity.

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