MCP is bidirectional. Servers do not only expose tools, resources, and prompts; they can also request capabilities from the client when those capabilities were negotiated during initialization.
Sampling lets a server ask the client to perform model generation while the client retains control over model selection, permissions, and user review. Elicitation supports form mode for structured input and URL mode for sensitive interactions that must happen outside the MCP client.
The 2025-11-25 specification also introduced experimental tasks for deferred and long-running operations. Tasks wrap supported requests in durable state that can be polled, cancelled, and completed later.
These features are optional. Correct implementations advertise and check capabilities instead of assuming that every host supports them.
| Feature | Request Direction | Primary Purpose |
|---|---|---|
| Sampling | Server to client | Ask the host-controlled model to generate a response |
| Elicitation | Server to client | Request additional structured user input |
| Roots | Client to server | Expose approved filesystem work boundaries |
| Tasks | Either direction where supported | Represent deferred, pollable, cancellable work |
A server may need model reasoning during a capability workflow. Instead of embedding its own model credentials, it can send `sampling/createMessage` through the MCP client. The client decides whether to allow the request and which model to use.
The server can provide messages, model preferences, a requested token limit, and context preferences. These are requests rather than authority: the client may modify or reject them.
Form-mode elicitation lets a server request a small structured form from the user through the client. It is useful when a tool workflow discovers that a required non-sensitive choice or field is missing.
URL-mode elicitation directs the user to an external HTTPS page for credentials, payment authorization, OAuth, or other sensitive interactions that must not pass through the MCP client. The client should show the destination and obtain consent before navigation.
Tasks are experimental in the 2025-11-25 specification. They let a request receiver acknowledge work immediately and return a task identifier instead of holding the original request open until expensive work completes.
The requestor can inspect status, retrieve the final result, list tasks, or cancel a task when those operations were negotiated. Typical states include working, input required, completed, failed, and cancelled.
Bidirectional features create more outcomes than a normal request-response call. A user can decline elicitation, a host can reject sampling, and a task can fail or be cancelled.
Treat these outcomes as normal workflow branches. Preserve partial progress, return a clear status, and avoid retrying user-facing requests in a loop.
Sampling can expose context to a model, elicitation can collect user data, and tasks can retain state beyond the original request. Each feature therefore needs explicit consent, data minimization, retention rules, and auditability.
The host remains the user-facing trust boundary. Servers should request the least information and capability necessary to finish the current workflow, and sensitive input should travel directly to a trusted HTTPS destination through URL-mode elicitation rather than through the MCP client.
Sampling, elicitation, and tasks are advanced because they let the server participate in a richer workflow than simple request-response capability calls. Sampling lets a server ask the client-controlled model for generation. Elicitation lets a server ask the user for missing input through the client. Tasks let supported requests become deferred, pollable work. Each feature is useful, but each increases the number of states the system must handle.
The safe design order is capability negotiation first, user trust second, and workflow recovery third. A server should not assume the client supports sampling or elicitation. A client should not hide from users when a server is asking for model work or user input. Both sides should handle decline, cancellation, timeout, and unsupported-feature paths as normal outcomes.
Use these features when they simplify a real workflow. If a server can complete work with an ordinary tool response, do that. If it needs model judgment owned by the host, use sampling. If it needs a non-sensitive missing choice, use form elicitation. If it needs credentials or payment authorization, use URL-mode elicitation. If work is long-running, use tasks where supported rather than holding a fragile request open.
Bidirectional MCP workflows need explicit state tracking. A sampling request may be approved, modified, rejected, or produce output that the server must validate. An elicitation request may be accepted, declined, cancelled, or abandoned. A task may be working, waiting for input, completed, failed, or cancelled. Treat each result as a normal branch.
For sampling, log why the server requested model help, what context was requested, whether the client allowed it, and how the generated result was used. For elicitation, log the prompt, mode, user decision, and safe correlation identifier. For tasks, log creation time, owner, status transitions, cancellation, and result retrieval.
The expert rule is to avoid hidden waiting. If the workflow is waiting for a user, model, or background task, the client and user should be able to see that status. Hidden pending states create support tickets and make recovery difficult.
The stable `2025-11-25` specification lets a server include tools and a tool-choice policy in `sampling/createMessage`. The client must advertise `sampling.tools` before the server sends such a request. The host still chooses the model, applies user policy, executes or mediates tool calls, and may reject the request.
Every assistant tool-use block must be matched by a following user message containing only tool-result blocks before the conversation continues. This strict sequence improves compatibility across model providers and prevents unresolved tool calls from leaking into later turns.
The older `includeContext` values `thisServer` and `allServers` are soft-deprecated. Omit them unless the client explicitly advertises `sampling.context`, and prefer sending the smallest explicit context needed for the operation.
Core tasks in `2025-11-25` remain experimental and use operations such as `tasks/get`, `tasks/result`, `tasks/list`, and `tasks/cancel`. Implementations must negotiate those capabilities and bind task access to the same authorization context as the underlying request.
The upcoming 2026 protocol work moves tasks into the `io.modelcontextprotocol/tasks` extension with a different wire contract. The extension is not compatible with the experimental core task surface: it removes `tasks/result` and `tasks/list`, adds `tasks/update`, and changes negotiation and result discrimination.
Pin the protocol revision and task surface in tests. A compatibility adapter may support both, but it must dispatch from negotiated capabilities rather than guessing from a task ID or silently translating incompatible messages.
The server asks the client for a bounded model response. The client remains free to approve, modify, or reject it.
{
"jsonrpc": "2.0",
"id": 41,
"method": "sampling/createMessage",
"params": {
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": "Summarize the validated incident timeline."
}
}
],
"maxTokens": 300
}
}A server requests a non-sensitive user choice using a restricted JSON schema.
{
"jsonrpc": "2.0",
"id": 42,
"method": "elicitation/create",
"params": {
"message": "Choose the environment for this deployment plan.",
"requestedSchema": {
"type": "object",
"properties": {
"environment": {
"type": "string",
"enum": ["development", "staging", "production"]
}
},
"required": ["environment"]
}
}
}For OAuth, credentials, payments, or other sensitive input, the server asks the client to open a trusted external page instead of collecting the data in an MCP form.
{
"jsonrpc": "2.0",
"id": 43,
"method": "elicitation/create",
"params": {
"mode": "url",
"message": "Connect your incident-management account.",
"url": "https://accounts.example.com/oauth/authorize",
"elicitationId": "connect-incident-account-7f31"
}
}Experimental tasks let a receiver return durable work state for a long-running tool call.
{
"jsonrpc": "2.0",
"id": 44,
"method": "tools/call",
"params": {
"name": "generate_compliance_report",
"arguments": {
"quarter": "2026-Q2"
},
"task": {
"ttl": 3600000
}
}
}No. The server can express preferences, but the client controls model selection and may modify or reject the request.
Not through form mode. Sensitive interactions must use URL mode so the data does not pass through the MCP client.
Tasks were introduced as experimental in the 2025-11-25 specification, so implementations should pin protocol expectations and prepare for evolution.
Explore 500+ free tutorials across 20+ languages and frameworks.