MCP Client Features Today: Elicitation Stays, Roots and Sampling Deprecated (SEP-2577)

One thing to know before writing an MCP client: the 2026-07-28 spec version adopted SEP-2577, deprecating the Roots and Sampling client features -- under the feature lifecycle policy, both remain in the spec for at least 12 months and new implementations SHOULD NOT adopt them. The only client feature retained and evolving is Elicitation, which gained a new URL mode. Based on the three official spec pages re-fetched on 2026-09-08, this article breaks down the current status, the deprecation context, and the migration paths for existing implementations.

1. Status Overview: One Retained, Two Deprecated

Two common lifecycle rules: deprecated features remain in the spec for at least 12 months from the release before becoming removable; new implementations SHOULD NOT adopt them, and existing implementations SHOULD migrate.

2. Elicitation: The Retained Feature's Dual Modes

Elicitation lets servers request additional information from users through the client during request processing -- the client keeps control over user interactions and data sharing. The 2026-07-28 version extends it into two modes:

Form Mode: Structured Data Collection

The server requests structured data with an optional JSON Schema validating the response. The capability declaration looks like elicitation: {form: {}, url: {}} (an empty object is equivalent to declaring Form mode only, for backwards compatibility); declaring parties must support at least one mode, and servers must not send requests using undeclared modes.

{
  "_meta": {
    "io.modelcontextprotocol/clientCapabilities": {
      "elicitation": { "form": {}, "url": {} }
    }
  }
}

URL Mode: Sensitive Interactions Completed Out of Band

The server directs the user to an external URL for sensitive interactions -- those never pass through the MCP client. The spec's example is API-key provision: the request carries mode: "url", the target url, and a message; the user's action: "accept" means consent to proceed, but the interaction happens out of band and the client is not directly informed of the outcome

{
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "url": "https://mcp.example.com/ui/set_api_key",
    "message": "Please provide your API key to continue."
  }
}

-- when the client retries the original request, the server determines completion from the echoed requestState. The docs also call out a major use case: URL mode can host OAuth authorization flows, connecting directly to the authorization chain design in MCP Authorization Explained: How OAuth 2.1 Lands in MCP (2026-07-28 Spec).

Security Red Lines (MUST-level)

• Servers MUST NOT use Form mode to request passwords, API keys, access tokens, or payment credentials;
• Such sensitive interactions MUST use URL mode. "Sensitive information" means secrets and credentials that grant access or authorize transactions; general contact or profile information is not categorically prohibited -- that is the server's discretion, subject to user review and refusal.

Client-side MUSTs: the UI must make clear which server is requesting information; provide clear decline and cancel options; allow reviewing and modifying Form responses before sending; and for URL mode, display the target domain/host and gather user consent before navigation.

{
  "action": "accept",
  "content": { "propertyName": "value" }
}

(URL-mode accept carries no content; decline and cancel are the other two actions.)

3. Roots: The Exit of Informational Guidance

Roots' original design: clients expose filesystem "roots" to servers, informing them which directories and files are relevant so operations stay focused. The spec carried two limits from the start -- it was informational guidance, not access control, and the protocol never enforced that servers stay within roots; the uri had to be a file:// URI.

The migration direction (quoted from the deprecation notice): pass directories and files via tool parameters, resource URIs, or server configuration. Migration note: implementations that treated roots as a "permission boundary" must redesign -- it never was one, and the deprecation merely makes that explicit.

4. Sampling: The Exit of the Borrowed Model Channel

Sampling's original design: servers request LLM sampling (completions / generations) through the client, supporting text, audio, and image interactions with MCP context in prompts -- valuable because the client kept control of model access, selection, and permissions while servers needed no API keys of their own. It came with full constraints: there SHOULD always be a human in the loop able to deny sampling requests; clients should offer UIs to review and edit prompts; tool-enabled sampling required the sampling.tools capability and servers must not send it to non-declaring clients.

The migration direction: integrate directly with LLM provider APIs -- control and credential management for model calls return to the implementor's own provider integration. Existing usage keeps working during the 12-month retention window; new implementations should not declare the sampling capability.

5. Migration Checklist and Common Mistakes

• Inventory capability declarations first: roots, sampling, and sampling.tools declarations and call sites are all on the migration list; replace the alternative path before withdrawing old declarations to avoid functional gaps.
• Replacing Roots with "configuration" is not a rename: once paths arrive via tool parameters, path validation and permission boundaries are your implementation's job -- it was never access control, and now it is explicitly not.
• Sampling replacement needs its own safety design: with direct provider APIs, the "human-in-the-loop approval via the client" protection is gone; prompt-injection defense and cost control are now yours to implement.
• Stay inside Elicitation's red lines: requesting API keys via Form mode is a MUST-level violation; sensitive interactions always go URL mode with domain display and consent.
• Declare capabilities precisely: declaring features you do not support -- or omitting ones you do -- makes peer behavior unpredictable (servers must not send requests using undeclared client features).

6. Next Steps

• The authorization chain (connecting to Elicitation's URL mode): MCP Authorization Explained: How OAuth 2.1 Lands in MCP (2026-07-28 Spec).
• The implementation-level security checklist: MCP Security Guide: The 8 Official Attack Vectors and Their Mitigations.
• The local transport's mechanics: MCP stdio Transport Deep Dive: Message Framing, Process Lifecycle, and Backward Compatibility (2026-07-28 Spec).