modelcontextprotocol · claude · Jul 10, 2026 · Jul 14, 2026 · Jul 14, 2026 · Jul 17, 2026
@@ -918,7 +918,7 @@
     },
     {
       "source": "/docs/concepts/sampling",
-      "destination": "/specification/2025-06-18/client/sampling"
+      "destination": "/specification/latest/client/sampling"
     },
     {
       "source": "/docs/concepts/tools",

@@ -129,9 +129,14 @@ For more details about server primitives see [server concepts](./server-concepts
 
 MCP also defines primitives that _clients_ can expose. These primitives allow MCP server authors to build richer interactions.
 
-- **Sampling**: Allows servers to request language model completions from the client's AI application. This is useful when server authors want access to a language model, but want to stay model-independent and not include a language model SDK in their MCP server. They can use the `sampling/createMessage` method to request a language model completion from the client's AI application.
-- **Elicitation**: Allows servers to request additional information from users. This is useful when server authors want to get more information from the user, or ask for confirmation of an action. They can use the `elicitation/create` method to request additional information from the user.
-- **Logging**: Enables servers to send log messages to clients for debugging and monitoring purposes.
+- **Elicitation**: Allows servers to request additional information from users. This is useful when server authors want to get more information from the user, or ask for confirmation of an action. Servers request user input with the `elicitation/create` method.
+
+Elicitation requests are delivered through the [Multi Round-Trip Requests](/specification/draft/basic/patterns/mrtr) pattern, explained in the [elicitation overview](/docs/draft/learn/client-concepts#elicitation).
+
+**Deprecated**: The following client primitives are deprecated as of protocol version `2026-07-28`.
+
+- **Sampling**: Allows servers to request language model completions from the client's AI application. This is useful when server authors want access to a language model, but want to stay model-independent and not include a language model SDK in their MCP server. Servers request completions with the `sampling/createMessage` method, also delivered through the Multi Round-Trip Requests pattern. New implementations should integrate directly with LLM provider APIs.
+- **Logging**: Enables servers to send log messages to clients for debugging and monitoring purposes. New implementations should log to `stderr` (stdio transport) or use OpenTelemetry.
 
 For more details about client primitives see [client concepts](./client-concepts).
 

@@ -25,6 +25,13 @@ Elicitation enables servers to request specific information from users during in
 
 Elicitation provides a structured way for servers to gather necessary information on demand. Instead of requiring all information up front or failing when data is missing, servers can pause their operations to request specific inputs from users. This creates more flexible interactions where servers adapt to user needs rather than following rigid patterns.
 
+Elicitation supports two modes:
+
+- **Form mode**: The server asks the client to collect structured data from the user. The request includes a schema that the client uses to build an input form and validate the response.
+- **URL mode**: The server provides a URL for the user to open. The interaction happens out of band and its data never passes through the client, which makes this mode suitable for sensitive flows such as credential entry or third-party OAuth authorization.
+
+Elicitation follows the [Multi Round-Trip Requests](/specification/draft/basic/patterns/mrtr) (MRTR) pattern. When a server needs user input while processing a request such as `tools/call`, it responds with an `InputRequiredResult` whose `inputRequests` field carries one or more `elicitation/create` requests. The client gathers the input and retries the original request, attaching the collected `inputResponses` and echoing back any `requestState` the server included.
+
 **Elicitation flow:**
 
 ```mermaid
@@ -33,27 +40,30 @@ sequenceDiagram
     participant Client
     participant Server
 
-    Note over Server,Client: Server initiates elicitation
-    Server->>Client: elicitation/create
+    Client->>Server: tools/call (id: 1)
+    Note over Server: Server needs more information
+    Server-->>Client: InputRequiredResult with elicitation/create request
 
     Note over Client,User: Human interaction
     Client->>User: Present elicitation UI
     User-->>Client: Provide requested information
 
-    Note over Server,Client: Complete request
-    Client-->>Server: Return user response
+    Note over Client,Server: Retry request with user input
+    Client->>Server: tools/call (id: 2, inputResponses)
 
     Note over Server: Continue processing with new information
+    Server-->>Client: Final result
 ```
 
-The flow enables dynamic information gathering. Servers can request specific data when needed, users provide information through appropriate UI, and servers continue processing with the newly acquired context.
+The flow enables dynamic information gathering. Servers can request specific data when needed, users provide information through appropriate UI, and servers complete the retried request with the newly acquired context.
 
-**Elicitation components example:**
+**Elicitation request example (delivered inside `InputRequiredResult.inputRequests`):**
 
 ```typescript
 {
   method: "elicitation/create",
   params: {
+    mode: "form",
     message: "Please confirm your Barcelona vacation booking details:",
     requestedSchema: {
       type: "object",
@@ -100,10 +110,19 @@ Elicitation interactions are designed to be clear, contextual, and respectful of
 
 **Response options**: Users can provide the requested information through appropriate UI controls (text fields, dropdowns, checkboxes), decline to provide information with optional explanation, or cancel the entire operation. Clients validate responses against the provided schema before returning them to servers.
 
-**Privacy considerations**: Elicitation never requests passwords or API keys. Clients warn about suspicious requests and let users review data before sending.
+**URL handling**: For URL mode, clients show the full URL and gather explicit consent before opening it, and never fetch the URL automatically. The client only learns whether the user consented. The interaction itself stays between the user and the target site.
+
+**Privacy considerations**: Servers must not use form mode to request sensitive information such as passwords, API keys, access tokens, or payment credentials. Those interactions belong in URL mode, which keeps the data out of band so it never passes through the client or the LLM context. Clients warn about suspicious requests and let users review form data before sending.
 
 ### Roots
 
+<Warning>
+  Roots are [deprecated](/specification/draft/deprecated) as of protocol version
+  `2026-07-28` and scheduled for removal. New implementations should pass
+  directories or files via tool parameters, resource URIs, or server
+  configuration instead.
+</Warning>
+
 Roots define filesystem boundaries for server operations, allowing clients to specify which directories servers should focus on.
 
 #### Overview
@@ -119,7 +138,7 @@ Roots are a mechanism for clients to communicate filesystem access boundaries to
 }
 ```
 
-Roots are exclusively filesystem paths and always use the `file://` URI scheme. They help servers understand project boundaries, workspace organization, and accessible directories. The roots list can be updated dynamically as users work with different projects or folders, with servers receiving notifications through `roots/list_changed` when boundaries change.
+Roots are exclusively filesystem paths and always use the `file://` URI scheme. They help servers understand project boundaries, workspace organization, and accessible directories. The roots list can change as users work with different projects or folders. Servers pick up the updated boundaries the next time they request the roots list.
 
 #### Example: Travel Planning Workspace
 
@@ -133,7 +152,7 @@ The client provides filesystem roots to the travel planning server:
 
 When the agent creates a Barcelona itinerary, well-behaved servers respect these boundaries—accessing templates, saving the new itinerary, and referencing client documents within the specified roots. Servers typically access files within roots by using relative paths from the root directories or by utilizing file search tools that respect the root boundaries.
 
-If the agent opens an archive folder like `file:///Users/agent/archive/2023-trips`, the client updates the roots list via `roots/list_changed`.
+If the agent opens an archive folder like `file:///Users/agent/archive/2023-trips`, the client adds it to the roots list, and the server sees the new boundary on its next `roots/list` request.
 
 For a complete implementation of a server that respects roots, see the [filesystem server](https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem) in the official servers repository.
 
@@ -153,12 +172,22 @@ Roots are typically managed automatically by host applications based on user act
 
 ### Sampling
 
+<Warning>
+  Sampling is [deprecated](/specification/draft/deprecated) as of protocol
+  version `2026-07-28` and scheduled for removal. New implementations should
+  integrate directly with LLM provider APIs instead.
+</Warning>
+
 Sampling allows servers to request language model completions through the client, enabling agentic behaviors while maintaining security and user control.
 
 #### Overview
 
 Sampling enables servers to perform AI-dependent tasks without directly integrating with or paying for AI models. Instead, servers can request that the client—which already has AI model access—handle these tasks on their behalf. This approach puts the client in complete control of user permissions and security measures. Because sampling requests occur within the context of other operations—like a tool analyzing data—and are processed as separate model calls, they maintain clear boundaries between different contexts, allowing for more efficient use of the context window.
 
+Sampling follows the same [Multi Round-Trip Requests](/specification/draft/basic/patterns/mrtr) flow described under [elicitation](#elicitation), with the `InputRequiredResult` carrying a `sampling/createMessage` request.
+
+Servers can also request tool use during sampling by including a `tools` array and an optional `toolChoice` field in the request. The tool definitions are scoped to that sampling request and do not need to correspond to tools the server exposes. Clients declare support through the `sampling.tools` capability, and servers must not send tool-enabled sampling requests to clients that have not declared it. See [sampling](/specification/draft/client/sampling#tools-in-sampling) in the specification for details.
+
 **Sampling flow:**
 
 ```mermaid
@@ -168,8 +197,9 @@ sequenceDiagram
     participant Client
     participant Server
 
-    Note over Server,Client: Server initiates sampling
-    Server->>Client: sampling/createMessage
+    Client->>Server: tools/call (id: 1)
+    Note over Server: Server needs an LLM completion
+    Server-->>Client: InputRequiredResult with sampling/createMessage request
 
     Note over Client,User: Human-in-the-loop review
     Client->>User: Present request for approval
@@ -183,11 +213,12 @@ sequenceDiagram
     Client->>User: Present response for approval
     User-->>Client: Review and approve/modify
 
-    Note over Server,Client: Complete request
-    Client-->>Server: Return approved response
+    Note over Client,Server: Retry request with approved response
+    Client->>Server: tools/call (id: 2, inputResponses)
+    Server-->>Client: Final result
 ```
 
-The flow ensures security through multiple human-in-the-loop checkpoints. Users review and can modify both the initial request and the generated response before it returns to the server.
+The flow ensures security through multiple human-in-the-loop checkpoints. Users review and can modify both the initial request and the generated response before the client retries the original request with it.
 
 **Request parameters example:**
 
@@ -196,9 +227,12 @@ The flow ensures security through multiple human-in-the-loop checkpoints. Users
   messages: [
     {
       role: "user",
-      content: "Analyze these flight options and recommend the best choice:\n" +
-               "[47 flights with prices, times, airlines, and layovers]\n" +
-               "User preferences: morning departure, max 1 layover"
+      content: {
+        type: "text",
+        text: "Analyze these flight options and recommend the best choice:\n" +
+              "[47 flights with prices, times, airlines, and layovers]\n" +
+              "User preferences: morning departure, max 1 layover"
+      }
     }
   ],
   modelPreferences: {
@@ -232,4 +266,4 @@ While not a requirement, sampling is designed to allow human-in-the-loop control
 
 **Configuration options**: Users can set model preferences, configure auto-approval for trusted operations, or require approval for everything. Clients may provide options to redact sensitive information.
 
-**Security considerations**: Both clients and servers must handle sensitive data appropriately during sampling. Clients should implement rate limiting and validate all message content. The human-in-the-loop design ensures that server-initiated AI interactions cannot compromise security or access sensitive data without explicit user consent.
+**Security considerations**: Both clients and servers must handle sensitive data appropriately during sampling. Clients should implement rate limiting and validate all message content. The human-in-the-loop design ensures that server-requested AI interactions cannot compromise security or access sensitive data without explicit user consent.
@@ -18,8 +18,9 @@ MCP provides several tools for debugging at different levels:
    [resources](/specification/latest/server/resources), and watch the
    notification stream. This should be your first stop.
 2. **Server logging**: structured logs to stderr (stdio transport) or via
-   [`notifications/message`](/specification/latest/server/utilities/logging#log-message-notifications)
-   (all transports).
+   [OpenTelemetry](https://opentelemetry.io/) (all transports).
+   [Logging](/specification/draft/server/utilities/logging) over the protocol
+   (`notifications/message`) is deprecated as of protocol version `2026-07-28`.
 3. **Client developer tools**: most MCP clients expose logs and connection
    state. See [Debugging in Claude Desktop](#debugging-in-claude-desktop)
    below for one example, or consult your client's documentation.
@@ -41,12 +42,18 @@ will interfere with protocol operation.
 </Warning>
 
 For servers using the
-[Streamable HTTP transport](/specification/latest/basic/transports#streamable-http),
-stderr is not captured by the client. Use the log message notifications below,
-your own server-side log aggregation, or standard HTTP tooling (curl, browser
-DevTools Network panel) to inspect requests,
-[`Mcp-Session-Id` headers](/specification/latest/basic/transports#session-management),
-and SSE streams.
+[Streamable HTTP transport](/specification/draft/basic/transports/streamable-http),
+stderr is not captured by the client. Use your own server-side log aggregation
+or [OpenTelemetry](https://opentelemetry.io/) for logs, and standard HTTP
+tooling (curl, browser DevTools Network panel) to inspect requests and SSE
+streams.
+
+<Warning>
+
+The `notifications/message` mechanism below is deprecated as of protocol
+version `2026-07-28`. It remains available during the deprecation window.
+
+</Warning>
 
 For all [transports](/specification/latest/basic/transports), you can also
 provide logging to the client by sending a log message notification:
@@ -74,10 +81,11 @@ await server.sendLoggingMessage({
 
 MCP defines eight
 [RFC 5424 severity levels](/specification/latest/server/utilities/logging#log-levels)
-(`debug` through `emergency`). Clients can adjust the minimum level at runtime
-via the
-[`logging/setLevel`](/specification/latest/server/utilities/logging#setting-log-level)
-request.
+(`debug` through `emergency`). Clients opt in to log messages per request by
+setting the
+[`io.modelcontextprotocol/logLevel`](/specification/draft/server/utilities/logging#per-request-log-level)
+field in the request's `_meta`. Servers must not send `notifications/message`
+for requests that omit this field.
 
 Important events to log:
 
@@ -173,17 +181,19 @@ When servers fail to connect:
 2. Verify server process is running
 3. Test standalone with [Inspector](/docs/draft/tools/inspector)
 4. Verify
-   [protocol compatibility](/specification/latest/basic/lifecycle#version-negotiation)
-5. Check
-   [capability negotiation](/specification/latest/basic/lifecycle#capability-negotiation):
-   error [`-32602`](/specification/latest/basic/lifecycle#error-handling) is
-   the standard JSON-RPC "Invalid params" code and is returned in many
-   contexts. One common cause is a server sending
+   [protocol compatibility](/specification/draft/basic/versioning#protocol-version-negotiation)
+5. Check the declared capabilities: error
+   [`-32602`](/specification/draft/basic#error-codes) is the standard
+   JSON-RPC "Invalid params" code and is returned in many contexts, including
+   requests whose `_meta` is missing a required field. A server that returns
    [sampling](/specification/latest/client/sampling) or
-   [elicitation](/specification/latest/client/elicitation) requests to a
-   client that hasn't declared that capability. Inspect the
-   [`initialize` exchange](/specification/latest/basic/lifecycle#initialization)
-   to verify both sides declared what you expect
+   [elicitation](/specification/latest/client/elicitation) requests in an
+   [`InputRequiredResult`](/specification/draft/basic/patterns/mrtr) needs the
+   client to declare the matching capability, and responds with
+   [`-32021` (`MissingRequiredClientCapability`)](/specification/draft/basic#error-codes)
+   when a required capability is missing. Inspect the
+   `io.modelcontextprotocol/clientCapabilities` field in your requests'
+   `_meta` to verify the client declares what you expect
 
 ## Debugging in Claude Desktop