What is MCP elicitation and sampling?

Why servers need to reach back

A plain tool call is request and response: the client invokes tools/call, the server runs, the server returns a result. That works until the server hits something it cannot answer on its own. Maybe it needs a value the user never supplied, like which repository to publish to. Maybe it needs the model to summarize a document before it can proceed. Elicitation and sampling are the two channels the Model Context Protocol gives a server to handle exactly these cases without giving up control or holding secrets it should not have.

Elicitation: asking the user

To request information from a user, a server sends an elicitation/create request. The result carries an action field with one of three values, accept, decline, or cancel, plus a content object that is present only on accept. This is stable, released behavior in the 2025-11-25 specification.

An elicitation request has a mode. Form mode (the default if mode is omitted) carries a message and a requestedSchema, a JSON Schema restricted to a flat object of primitive types, so the client can render a simple form. URL mode, added in 2025-11-25, carries a message, a url, and an elicitationId for out-of-band flows. Form mode and URL mode exist to keep sensitive input off the form path.

The trust rules are normative, not advisory. Servers MUST NOT use form mode to request sensitive information such as passwords, API keys, access tokens, or payment credentials, and MUST use URL mode for those instead. Clients MUST provide UI that makes it clear which server is requesting information, and MUST respect user privacy with clear decline and cancel options. The user is always in the loop.

Sampling: asking the client model

To request a language model generation, a server sends a sampling/createMessage request. The result returns a role and content plus the model used and a stopReason. As the spec puts it, sampling allows servers to implement agentic behaviors by enabling LLM calls to occur nested inside other MCP server features. A server can reason about its own inputs without ever shipping with model credentials.

Crucially, the client controls model selection, and the server never sees an API key. The client picks the model, can review and edit the prompt before sending, and can deny the request outright. The schema encodes this directly: the client has full discretion over which model to select, and should inform the user before sampling so they can inspect the request and decide whether to approve it. For trust and safety there SHOULD always be a human in the loop able to deny sampling requests.

Because the server should not hardcode a model name, sampling uses an abstract preference system. A request can carry modelPreferences with hints (advisory model-name substrings) plus costPriority, speedPriority, and intelligencePriority values from 0 to 1. Hints are advisory; the client makes the final model choice. A server says it wants something cheap and fast, or something capable, and the client maps that onto a model it trusts.

Sampling can go further. A sampling request can itself carry a tools array and an optional toolChoice (auto, required, or none), letting the client model call tools, receive results, and continue the conversation inside a single sampling flow. That is the agentic loop, and the spec gates it at every step with human-in-the-loop approval.

How the two combine, and the draft round-trip pattern

In the released 2025-11-25 spec, both capabilities work as server-initiated JSON-RPC requests issued while an operation is in progress: the server sends elicitation/create or sampling/createMessage nested inside the call it is handling, and the client returns an ElicitResult or a CreateMessageResult. That keeps a connection open for the duration.

The upcoming next version reshapes this. As of the 2026-07-28 release candidate, the Multi Round-Trip Requests pattern (SEP-2322) replaces server-initiated requests such as roots/list, sampling/createMessage, and elicitation/create. The candidate is locked but not yet final, so treat these names as the draft schema, not a shipped release.

The mechanics, confirmed in the draft schema, work like this. A result can carry a resultType of input_required whose body is an InputRequiredResult. That interface has two optional fields: inputRequests (a map of server-initiated requests the client must fulfill) and requestState (an opaque blob the client must echo back unmodified on retry). At least one of the two MUST be present. The client must treat requestState as opaque and not interpret it in any way.

On retry, the client re-issues the original call carrying inputResponses (a map keyed identically to inputRequests) and the echoed requestState. InputRequiredResult is returned in place of the normal result for tools/call, prompts/get, and resources/read, so any of those calls can pause and demand input instead of completing. Each value in inputRequests is itself a full elicitation or sampling request, so one round-trip can batch an elicitation/create and a sampling/createMessage together, each keyed by a server-assigned id, and the matching inputResponses mirrors those keys with an ElicitResult and a CreateMessageResult.

The payoff is statelessness. Because all the resume state lives in requestState rather than in a held connection, the server does not need to keep an SSE stream open or share a session store across instances. Any instance behind a load balancer can pick up the retry, read the echoed state, and continue. (Note that the same release candidate deprecates the standalone Roots, Sampling, and Logging client features under SEP-2577, with the spec's twelve-month minimum deprecation window, so verify the exact status of each feature before depending on it.)

What this enables for an agent-publishing flow

Consider a server that publishes HTML for an agent. The actions the model invokes, publish a site, update it, set a password or expiry, are tools, because tools are model-controlled. Listing the user's existing sites is a resource, because resources are application-controlled data the client reads. A saved workflow like "publish this report privately" fits a prompt, because prompts are user-controlled templates a person explicitly invokes.

Elicitation and sampling are what make that flow feel responsible rather than blind. If a publish call is missing the gating choice, the server elicits it: accept, decline, or cancel, with the user seeing exactly which server asked. If the report needs a one-line summary for its meta description, the server samples the client model rather than guessing or calling out to a model of its own. The user approves the model use, and no key ever leaves the client. The server stops being a passive endpoint and becomes a participant that asks before it acts.