MCP roots, sampling and logging deprecated: Sume impact
The 2026-07-28 MCP spec deprecates Roots, Sampling and Logging. Sume's hosted server declares only tools, so a client calling it has nothing to migrate.

If you call Sume's hosted MCP server, deprecating Roots, Sampling and Logging changes nothing you have to do. Sume's initialize answer declares only a tools capability, and the server code has no method that asks the client for roots, sampling or logging. What you send Sume goes in tool parameters, which is the migration the spec itself suggests.
The deprecation is from the MCP project's 2026-07-28 key changes, read 2026-09-29. The Sume side is the hosted server code and the MCP tools and gates page.
What did the spec deprecate?
The changelog lists a deprecation of the Roots, Sampling and Logging features. It says they "remain fully functional during the deprecation window" but new implementations should not add support for them.
| Deprecated feature | Suggested migration |
|---|---|
| Roots | Pass directories or files via tool parameters, resource URIs, or server configuration |
| Sampling | Integrate directly with LLM provider APIs |
| Logging | Log to stderr (stdio) or use OpenTelemetry |
What does Sume's server declare?
In the hosted server's initialize result, capabilities holds tools with listChanged set to false and nothing else. Roots and Sampling are capabilities a client offers a server, and Logging is one a server offers; Sume advertises none of them.
A client that ignores or drops those features loses nothing when it talks to Sume. The tool calls still carry what Sume needs, such as prompts and public URLs.
Where do my inputs go instead of roots?
Into the tool arguments. The docs' playbook is: call a tool with dry_run=true, review the preview, repeat without dry_run to submit, poll with jobs_status or jobs_wait, then read jobs_result. Every input is an argument on that call, so there is no directory scope for a client to declare.
Files are the one place roots might have seemed useful, and the docs close that door: "Hosted MCP cannot read files from your laptop." The upload flow is to create an upload URL with assets_upload_url, have the client PUT the bytes, then call assets_complete. The client, not the server, moves the file, so no root is needed to say where it lives. Both tools are write tools and take an idempotency_key.
What about the new request pattern?
The same revision replaces server-initiated requests such as roots/list, sampling/createMessage and elicitation/create with Multi Round-Trip Requests: the server returns an input_required result and the client retries with inputResponses. Sume's tool calls do not ask for input mid-call, so a client can treat every tools/call result as final for that call.
The same changelog also reclassifies the HTTP+SSE transport as deprecated and points to Streamable HTTP. Sume's endpoint is a POST JSON-RPC endpoint; a GET to it answers 405 with "Remote MCP uses POST JSON-RPC requests." Point new clients at https://mcp.sume.com/mcp as a streamable HTTP server.
Sources
Related posts
More in Developers
- MCP Tasks extension: does Sume use it for long jobs?
No. Sume's hosted MCP server has no task handles. A paid create returns a job id, and you poll it with jobs_status or jobs_wait, then read jobs_result.
- MCP tools/list ttlMs and cacheScope: what is safe to cache?
The 2026-07-28 MCP spec adds ttlMs and cacheScope to tools/list. Sume's tool list depends on the session's scopes, which is why caching it per session matters.
- Unsupported MCP protocol version: the 400 from Sume's server
Sume's MCP endpoint answers an MCP-Protocol-Version it does not support with HTTP 400 and code -32600. Here is what the 2026-07-28 spec tells a client to do.
- MiniMax H3 4-second clips: MiniMax says 4, Sume says 5
MiniMax lists 4–15 seconds for H3, but Sume's docs and pricing code start at 5 seconds. Send 5 or more, and trim to 4 afterwards if you need it.
Written by Sume