MCP elicitation worksheet: consent is not completion

Use one record for one information request

An MCP server asks a user to supply information while an operation is in progress. A team needs to decide whether that particular interaction may proceed, and what evidence would let the original operation continue. Use the blank record below to keep those decisions separate.

For URL elicitation, action: accept means the user consented to the interaction. It does not establish that the external interaction finished. Both the legacy 2025-11-25 and captured current 2026-07-28 documents make that distinction.[1][2] A clicked link, a successful-looking browser page or a retry is not sufficient completion evidence for this worksheet.

PROCEED, HOLD and DECLINE are this worksheet’s proposed local decision labels, not MCP response actions. The protocol distinguishes accept, decline and cancel; cancel is dismissal without an explicit choice. Keep the user’s actual response separate from the team’s disposition.[1]

Copy the fields for one request. Record references to redacted implementation evidence, not secrets or opaque state. Use UNKNOWN for a gap and NOT APPLICABLE only with a reason. If the protocol era is unknown, hold the affected stage rather than guessing its completion mechanism.

Choose the mode from the data, not from convenience

Form mode exposes submitted data to the client. The client MUST identify the requesting server, provide clear decline/cancel options and let the user review and modify form responses. URL mode moves the sensitive interaction out of band; it is not permission to hide the destination or collect credentials through the client.[1] Third-party credentials acquired there MUST NOT transit through the MCP client.[1]

Purpose, minimization, retention and the named decision owner are additional worksheet policy fields. They are not new MCP MUST clauses. Ordinary contact data still deserves a reason for collection; its being permitted in form mode is not a blanket privacy approval.

Pin the actual protocol era before choosing completion fields

Official sources checked on 6 October 2026 KST led from the latest specification URL to 2026-07-28. That is the current revision observed for this resource, not evidence that a deployed client has upgraded. Its changelog describes the changes since 2025-11-25.[4] Record the actual client/server contract and supporting evidence, not just a documentation link.

In either era, an empty elicitation capability object means form-only, not URL support. Servers MUST NOT request an unsupported mode. A capability declaration establishes neither the deployed UI’s behavior nor its identity checks.[1][2] In the modern request, io.modelcontextprotocol/clientCapabilities is a key inside _meta, not a literal dotted key.

Elicitation remains a core feature here. If the integration also uses an optional extension, record its actual identifier, settings/version and enablement evidence separately. Optional extensions evolve independently; SDK implementation is optional, and developer opt-in is required. Unsupported extensions must fall back to core behavior or be rejected.[6][7] A generic SDK support statement does not close this record.

Establish the URL and user-binding controls

• The client MUST show the full URL for examination and obtain explicit consent before opening it. It MUST NOT automatically prefetch the URL or its metadata.[1]
• The opening method MUST prevent the MCP client and LLM from inspecting page content or user inputs. A declaration of URL support is not evidence of that isolation.[1]
• The server MUST NOT put end-user PII or secrets in the supplied URL, or supply a URL preauthenticated to a protected resource. HTTPS outside development, domain highlighting and suspicious-URI warnings are SHOULD guidance, not new unconditional MUSTs.[1]
• The server MUST bind the request to client and user identity, verify the user opening the URL before accepting information, and ensure the initiating and completing users match. It MUST NOT trust unverified client-provided identification.[1]

A self-entered email address does not establish authenticated identity. Ask for the verification mechanism and redacted evidence of association with the original request. A browser cookie/verified-subject comparison is one documentary example, not the only required mechanism.[1] Under the modern contract, MCP has no protocol-level sessions; application/browser context and server state handles are separate. Possession of a state handle MUST NOT count as authentication.[5] Legacy state likewise MUST NOT be associated with session IDs alone.[2]

If the server stores elicitation state, it MUST protect that storage and securely associate it with individual users. For remote MCP servers, user identification MUST be derived from credentials acquired via MCP authorization when possible.[1] Worksheet policy: record a redacted evidence reference rather than a real user identifier.

Examine the actual full URL privately before consent. In a shared decision record, keep only a sanitized host/path and a private evidence reference; the abbreviated record is not a substitute for that examination. Do not paste private query parameters, credentials or opaque requestState into the worksheet.

Check modern retry state without reading its contents

When InputRequiredResult supplies requestState, the client MUST echo it exactly on retry and MUST NOT inspect, parse or modify it. The retry uses a different JSON-RPC ID, and its inputRequests/requestState MUST NOT be applied to a different parallel request.[3] Keep an evidence reference for those controls, not the state payload.

The server treats requestState as attacker-controlled. If it influences authorization, resource access or business logic, integrity protection and rejection of invalid state are MUST requirements. Principal, expiry and originating-request binding are SHOULD guidance. Where at-most-once consumption is required, the server MUST enforce it; those bindings alone do not guarantee single-use.[3] This is not the legacy elicitationId and is not proof that the same user completed the interaction.

After URL consent, the server determines external completion when the original request is retried, from echoed state or its own stored state.[1] It may still need input. Separately record permission to retry, verified external outcome and the original operation’s final result. The server MUST handle user decline, cancellation and client-processing failure.[1]

Blank worksheet: request and applicability

Copy this and the next three field groups as one record. All fields are proposed recordkeeping policy; the explanations above identify the source’s MUST, SHOULD and MAY requirements. Do not put a real secret or private identity in the blanks.

• Record reference: [nonsecret reference]. Reviewer / decision owner / reviewed at with time zone: [ ].
• Bounded stage under review: [information collection / URL navigation / original-request retry / operation continuation].
• Requesting server / identity shown in client / supporting evidence: [ ].
• Client name and build / transport / actual protocol revision or era / evidence: [UNKNOWN allowed].
• Original operation / exact information requested / purpose: [ ].
• Minimum data needed / data class: [ordinary contact or profile / secret or transaction credential / unresolved]. Collection destination / retention or deletion policy: [ ].
• Requested mode: [ ]. Declared supported mode and evidence: [ ]. Implemented behavior and evidence: [separate entry; UNKNOWN allowed].
• Extension identifier / version or settings / explicit enablement evidence, if actually used: [NOT APPLICABLE / UNKNOWN / reference].

Blank worksheet: consent, privacy and identity

• Form path: no forbidden secret requested / server identified / review and edit available / decline and cancel visible: [separate evidence entries or NOT APPLICABLE].
• URL path: full URL examined privately before consent: [evidence reference or UNKNOWN]. Sanitized target host and path / domain review: [ ]; this abbreviated record does not replace full-URL examination.
• URL contains no end-user PII or secrets and grants no preauthenticated protected-resource access: [evidence or UNKNOWN]. Production HTTPS / any local exception and rationale: [ ].
• No automatic URL or metadata prefetch: [evidence or UNKNOWN]. Explicit consent before opening: [evidence or UNKNOWN].
• Opening method prevents client and LLM inspection of page content and user inputs: [evidence or UNKNOWN].
• Server-verified initiating user equals completing user: [verification method and redacted evidence or UNKNOWN]. Binding to the client, original request and appropriate browser/application context: [evidence or UNKNOWN].
• Stored user state, if any: protected storage and verified user association: [evidence or NOT APPLICABLE with reason]. A session ID or state handle alone is not identity evidence.
• Record hygiene: no password, API key, token, payment value, raw private URL, user identifier or opaque requestState copied here: [confirmed / needs redaction].

Blank worksheet: consent, completion and continuation

• User response: [NOT ASKED / ACCEPT / DECLINE / CANCEL / UNKNOWN]. For URL mode, ACCEPT records consent, not external completion.
• External interaction outcome: [PENDING / VERIFIED COMPLETE / FAILED / UNKNOWN / NOT APPLICABLE for a form-only request]. Redacted server-outcome evidence: [ ].
• Legacy 2025-11-25 original elicitationId and initiating-client correlation: [private reference / UNKNOWN]; for 2026-07-28: [NOT APPLICABLE, removed].
• Legacy optional completion notification: [YES / NO / UNKNOWN]; original ID recognized and not already completed: [evidence]. For 2026-07-28: [NOT APPLICABLE, removed].
• Modern inputRequests/inputResponses correlation and binding of retry to the original request: [evidence / UNKNOWN / legacy NOT APPLICABLE]. Retry uses a different JSON-RPC ID: [evidence / UNKNOWN].
• Modern requestState, if supplied: exact client echo without inspection or modification: [evidence reference / UNKNOWN / NOT APPLICABLE with reason]. Do not record the opaque value.
• Modern requestState server controls where applicable: integrity verification and rejection of invalid state / principal, expiry and original-request binding / server-side single-use when required: [separate evidence references, normative strength and gaps].
• Manual retry and cancel controls: [evidence / UNKNOWN]. Server handling of declined, cancelled, unresolved and client-failure paths: [ ].
• Permission to retry or continue the original operation: [not granted / bounded permission and owner / UNKNOWN]. Original-operation result: [PENDING / VERIFIED SUCCESS / FAILED / UNKNOWN].

Blank worksheet: disposition and named next action

• Disposition: [PROCEED / HOLD / DECLINE]. Permitted bounded stage and limits: [ ].
• Unresolved applicable MUST requirement: [exact requirement and source / none established]. Additional local-policy condition, including stricter treatment of SHOULD guidance: [separate entry].
• Named next-action owner / specific action / evidence needed / recheck condition: [ ].
• PROCEED is permission for this recorded stage only. It is neither proof of external completion nor a whole-system security certification.

Worked example: HOLD despite recorded consent

This is a hypothetical, unexecuted record. Example Desktop 1.0 and Example Expense Helper are fictional. Assume supplied records describe a 2026-07-28 URL interaction needed for one expense-service connection; that assumption is not verified product support. The target is inert host/path text: connect.example.invalid / connect. No URL was opened and no credential, payment, account or connection was used.

The missing modern completion notification is not the reason for HOLD: that notification was removed.[4] Even a hypothetical ACCEPT cannot establish the client’s controls or the external result.[1] In a contrasting form-only request for an API key, our policy is DECLINE that form request and ask its owner for an appropriate alternative; do not paste the key into a test.[1]

Interpret the record without certifying the integration

• DECLINE: the request is a known prohibited collection path, or the user does not agree. Preserve whether their protocol response was decline or cancel rather than rewriting one as the other.
• HOLD: an applicable mandatory requirement or explicitly adopted local-policy condition is unresolved. Name the missing evidence and the person responsible for obtaining it.
• PROCEED: evidence supports only the stated stage and its applicable controls. Permission to navigate is not permission for every external action; permission to retry is not evidence of completed work.

These are conservative local recommendations, not additional protocol enums or a security certification. A SHOULD can be adopted as a stricter team condition, but label that choice. A legacy completion notification is optional: its absence does not by itself prove failure. Unknown or already-completed legacy IDs must still be ignored.[2]

Sources and limits

This resource compares captured official elicitation, MRTR, changelog, schema, compatibility, extension and security passages, with 2025-11-25 as a legacy comparison.[1][2][3][4][5][6][7][8] Sources were checked on 6 October 2026 KST. Page publication/update dates were not established; protocol revision labels and retrieval dates are not launch or rollout dates. The observed latest-specification redirect does not establish future stability.

This is documentary guidance and proposed recordkeeping policy, not an interoperability experiment. No deployed client/server support, consent enforcement, user binding, credential handling, model access or account outcome was tested. UNKNOWN means unestablished, not failure or zero. Source-rendered code was not executed, and this resource supplies no copy-and-run wire JSON.