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

Annotations only declare openWorldHint=false and destructiveHint=false, so the description does real work by disclosing the three-state return semantics and the meaning of null ("dismissed" | "error") plus the follow-up advice to ask again later. It adds handling guidance rather than merely restating structured data, though it says nothing about the blocking/timeout behavior of the call itself.

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 what the tool does and its alternative before the longer return-value contract. Every clause carries information an agent needs; nothing is 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?

Output schema exists so return values need not be re-specified, yet the description still clarifies the ambiguous null case. Combined with the alternatives routing and full param documentation, an agent has everything required to call and interpret 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%, and the schema already documents message, labels (with length bounds and trimming rules), and timeoutSeconds clamping. The description's echoes of "OK/Cancel" and "single yes/no question" add only framing, not new 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?

Specific verb ("Ask the user") plus precise resource (OK/Cancel confirmation via elicitation) and it explicitly positions itself as a convenience wrapper over elicit_form. An agent can distinguish it from elicit_form, elicit_doctor, and elicit_display 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 rule: "Use this for a single yes/no question; use elicit_form to collect arbitrary fields." It gives both the when and the named alternative, 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?

Goes well past the readOnlyHint/openWorldHint annotations: HTML-escaping of {{ context.* }}, JS-style truthiness, permitted external origins (only cdn.jsdelivr.net), Tailwind/DaisyUI loading, data: URI fallback with differing size budgets, and the fact that the rendered HTML is never returned. The openWorldHint=false annotation is consistent with the allowlist disclosure, not contradicted.

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 constraints, then the return behavior — a sensible ordering with no filler. It is dense and the image guidance spans two overlapping sentences, but nearly every clause carries operational information an agent needs.

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 no output schema, the description covers the return contract explicitly ('the result only says whether it could be shown') plus all rendering constraints, escaping rules, and size limits. 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 coverage is 100%, so baseline is 3; the description still adds real meaning by explaining how template and context interact ({{ context.* }} interpolation, escaping rules), why images should go in context rather than the template (64 KB vs 32 KB), and that summary becomes the tool's text result.

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 (show information as rendered HTML) and the mechanism (LiquidJS template + JSON context), and explicitly distinguishes itself from the decision-collecting siblings elicit_confirm/elicit_form. An agent can identify this 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?

Gives explicit when-to-use (tables, reports, summaries the user should scan) and when-not (it does not collect a decision), naming the alternatives that do. The host-support caveat ('hosts that support MCP Apps render it inline') further bounds applicability.

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?

Goes beyond the readOnlyHint/openWorldHint annotations by disclosing that the default is a passive report derived from the initialize handshake, and that probeElicitation:true fires a live round-trip the user may see a dialog for. That side-effect disclosure is the key behavioral fact an agent needs. Doesn't cover cost/latency or persistence of the contributed fingerprint, so not a 5.

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 is front-loaded in the first clause and every sentence carries information (motivation, usage routing, return behavior, opt-in probe, safety). It is dense and slightly overstuffed for a one-parameter tool, but nothing is truly redundant.

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 fields, yet it still names probes.elicitationForm and distinguishes passive vs. probed output. Read-only safety, default behavior, and routing to siblings are all covered — 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?

Coverage is 100% and the schema description already explains probeElicitation, its default, and where the result lands (probes.elicitationForm). The description largely restates this, adding only the user-visible-dialog consequence, 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?

Specific verb+resource: 'Check whether the connected MCP host actually supports elicitation (and sampling/roots)'. It explicitly frames itself as the diagnostic step preceding elicit_form/elicit_confirm, so an agent can separate it from the sibling action tools 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?

Gives three concrete when-to-use cases ('decide whether to call elicit_form/elicit_confirm', 'explain why a prompt did or didn't appear', 'contribute a host capability fingerprint'), which is essentially a routing statement to the siblings. The 'advertising a capability is not the same as it working' note explains the failure mode that motivates the call.

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 establish this is non-destructive and not open-world, but the description goes further by disclosing the raw {action, content} return shape and a meaningful policy constraint against collecting secrets or credentials. Since an output schema exists, the return-shape sentence adds less than it otherwise would, leaving this just short of 5.

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 tight sentences that front-load the core action, followed by the alternative and the misuse guard. No filler and 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?

With annotations covering the safety profile, an output schema covering return values, and full parameter documentation in the schema, the description supplies the remaining routing and misuse-prevention context. An agent has everything needed to call it correctly and to know when not to.

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 (including default and clamp range), and the requestedSchema subset restriction in detail. The description adds the phrase 'caller-supplied JSON schema' but no syntax or semantics beyond what the schema provides, 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 ('Trigger a form elicitation with a caller-supplied JSON schema') and explicitly names the return shape. It also differentiates itself from the sibling elicit_confirm by routing plain OK/Cancel questions there.

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 both an alternative ('For a plain OK/Cancel question, prefer elicit_confirm') and a hard exclusion ('MUST NOT be used to request secrets, credentials, or other sensitive information'). The when-to-use and when-not-to-use conditions are explicit rather than implied.

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