MCPServer as a thin composition of the 2026 helpers

[maxisbey]

MCPServer composes the public helpers from the feature issues (MRTR, caching hints, HTTP headers, subscriptions/listen — and the existing schema-inference / registry helpers) into the high-level decorator API — thin, not a monolith with private machinery. Someone using lowlevel Server should be able to reach for the same building blocks.

What's in it

• Compose the public helpers: tool/resource/prompt registries, schema inference, cache hints, x-mcp-header annotations, MRTR signaling, listen publishing — exposed via @server.tool() / @resource() / @prompt() kwargs and ctx verbs.
• Design needed: how MCPServer presents MRTR and subscriptions/listen given the stateless/distributed nature of 2026 — there's no per-connection state to lean on and servers may be horizontally scaled (e.g. where does requestState live between rounds; how do listen publishers reach a stream that might be on another instance).
• Keep MCPServer itself thin: anything it does should be a public helper a lowlevel-Server user could call directly.

Conformance

• (SDK API surface — proven via in-repo / interaction tests)

Dependencies

• Depends on: Context object (layered, per-request) #2895
• Depends on: MRTR (multi-round-trip requests) #2898
• Depends on: Caching hints (ttlMs / cacheScope) #2899
• Depends on: HTTP standard headers + x-mcp-header #2900
• Depends on: subscriptions/listen #2901

References

• python-sdk MCPServer

[maxisbey]

Shipped in v2.0.0b1: MCPServer composes the public helpers (cache hints, header annotations, MRTR signaling, listen publishing) over the same building blocks available to lowlevel Server. The two open design questions this issue posed got concrete answers: requestState between rounds is a sealed client-carried envelope with no server-side state (#3032), and listen publishers reach cross-instance streams via the pluggable SubscriptionBus (#3035).

_{AI Disclaimer}