1. Sessions: Killing Transport Sessions, Defining Application Sessions

Problem being solved

• Current "session" concept conflates two things: a transport-level session (connection lifetime, capability negotiation) and an application-level session (grouping related tool calls within a conversation/context window).
• SDK behavior is inconsistent: C# SDK and FastMCP are stateless by default; the TypeScript SDK always generates a session ID unless explicitly suppressed.
• In real clients (e.g., Gemini CLI), the MCP session is not tied to the chat session — clearing chat or opening a new one reuses the same session ID, making it meaningless. Telemetry (Microsoft) shows the vast majority of usage is stateless tool calls anyway.
• Because MCP sessions are unreliable, clients have built their own internal session/agentic-flow management, creating friction for future features like tasks.

Direction agreed

• Decouple elicitation, sampling, and other features from sessions so they work independently.
• Transport sessions are obsolete - kill them.
• Introduce a new, explicitly client-driven concept (working names: "context" / "thread") for application-level grouping. Only the client knows which calls belong together.
• Default = no session. Clients must explicitly create / resume / end. Implicit session creation tied to client-object lifetime is what caused the current mess (one client shared across multiple chat windows).
• A proposed sessions capability on the server: create_session method + session_required / session_not_found errors so servers can declare strictness.
• Pushback: tying application state to sessions is "super messy," assumes linear episodic chats which may not be the future. Tools list etc. should not be session-scoped.
• For state freshness (resources, unsolicited notifications — currently spec'd as unreliable): proposal is DNS-style TTLs on resources so clients know how long to cache before refreshing.
• Migration will be a breaking change; needs a migration guide and likely SDK v2. Naming TBD ("session" and "context" both carry baggage).

2. Stateless Multi-Turn Tool Requests (Elicitation Behind Load Balancers)

Problem being solved

• The original elicitation model is stateful: server issues an elicitation request mid-tool-call and awaits the answer on the same connection (SSE / STDIO).
• This breaks behind a load balancer: the client's follow-up lands on a different server instance. It also breaks on any connection drop — long-running tool calls with multiple elicitations can't be resumed.

The "MRTR" stateless pattern (accepted by core maintainers)

• If the server needs more input, it rejects/fails-fast the tool call and returns "I need X."
• The client re-issues the original tool call with the elicited input pre-filled in the same payload.
• Server is now a standard stateless web handler; any replica can serve any step. State burden shifts to the client (or a request-state object passed back and forth).
• For complex multi-step flows, server transitions through stages via a request-state object — described as a more "agentic" pattern (do work → raise "need info" → resume).

Developer experience & compatibility

• DX concern: this is harder than the simple await elicit() model. Familiar to web/distributed devs, foreign to others. Classic RPC debate: make remote look local, or expose the difference?
• Resolution: SDKs will wrap MRTR internally so single-server / local cases can keep using the simple await style. Distributed servers manage the complexity themselves.
• Old stateful model: kept for backward compat, strongly discouraged in docs. New samples to be built for the stateless model.
• Type-safety concern raised for C# (must declare upfront what client input might be needed); plan is discriminated unions for complete vs incomplete result types.
• Elicitation is being used in the wild (mostly one MCP server today) and is in demand from Copilot Studio, Foundry, etc. — so this work is needed.
• Side note at end: worry about an impending supply-chain attack around servers, and that the API-key/token progression path for API clients is "not great" security-wise.

3. STDIO Transport — Security, Supply Chain, and Governance

Why STDIO still exists / is used

• Quick local one-offs ("tiny thing, didn't want to spin up a server").
• Controlling local applications (Chrome DevTools MCP, Ghidra reverse-engineering) where a remote server makes no sense.
• OS integration (Microsoft working on built-in MCP server support in Windows).
• Distribution convenience: ship a package, no hosting/auth needed.
• MCPB bundles; push-event channels added by some clients.

The core security problem

• STDIO = arbitrary local binary execution. It's effectively a software-distribution mechanism, not just a transport. You can't bake cryptographic assertions into "run this binary."
• Google's internal security team banned STDIO servers early (no inspection, uncontrolled quality); ban believed still in effect. Google treats almost everything as remote behind a service layer; STDIO allowed only for experiments.
• High-popularity STDIO servers (e.g., Desktop Commander, top-3 in many lists) are a reputational time bomb - one supply-chain attack would taint MCP broadly. Security teams already conflate STDIO risk with all of MCP.
• Transport isn't actually the root cause: removing STDIO just pushes people to run a local Streamable HTTP binary - same arbitrary-code risk, plus new risks (binding to 0.0.0.0, accidental network exposure, port-forwarding mistakes). The real issue is pulling and executing packages locally (npm/PyPI/npx malware, cf. recent axios compromise).

Mitigations discussed

• Not solvable at the protocol level. Sandboxing (Docker, microVMs) is an option, but MCP shouldn't be prescriptive about it.
• Registry-side controls are the only thing that meaningfully moves reputation/trust:
  • Package scanning and verified publisher badges.
  • Dependency aging - require pinned versions, don't allow direct npx <pkg> latest; delay availability ~a week so a malicious publish doesn't hit users instantly.
  • Best practice for security-conscious orgs: stand up a private registry and restrict clients to it.
• Client UX: treat STDIO as a distinct, higher-risk security class. Today VS Code adds STDIO and HTTP servers identically; should instead show a strong "you're about to run a local binary" warning (browser-download style). Acknowledged that users click through warnings, but it still helps.
• Capability/permission model (Android-style "this server needs disk write / network") was floated. Largely dismissed as security theater on desktop OSes — one permission (e.g., network) lets you pivot to everything; mobile only works because the OS sandbox is already strong. MCPB bundles (everything vendored) are seen as the existing step in this direction, just lacking traction.
• Enterprise: rely on OS-level policy (signed-binary requirements) rather than protocol.
• Reality check: many non-tech customers (e.g., healthcare on old Windows) npx random packages; PMs install Node for the first time to run an MCP server without understanding what npx does.

Action item: publish security best-practices docs - audit packages before running, pin dependencies, use private registries, package-manager hygiene. A managed/scanned registry is "probably the only real choice in an open world."

4. Standard Client Configuration Format (mcp.json) & Secret Handling

Goal

• A standard, drop-in client config file (analogous to what VS Code / Claude / Cursor each invent today) so a single config can be pasted into any client. Covers all connection types including remote MCP (where the inference API runs the MCP server and resolves tool loops with batching).
• Immediate forcing function: the Open Plugins proposal needs a canonical MCP server config format soon.
• Also enables deep-link install ("click to add this server to your client") and on-device registries for enterprise governance.

Scope decisions

• Standardize transport type naming (esp. Streamable HTTP) - clients currently disagree on the strings.
• Distinguish server.json (server-authored schema: required fields, secrets, validation) from the client config file (runtime values to actually launch/connect). Client config can store a reference back to server.json so clients can re-render validated, masked config UIs.
• Tool-selection criteria flagged as hard to normalize across clients.
• Token storage stays client-specific (each client uses its own keychain/vault); the config just declares what's needed.

Secret security (the bulk of the discussion)

• Current practice of passing secrets openly in config is concerning.
• Do NOT standardize arbitrary env-var injection — a malicious server config could exfiltrate machine env vars.
• Headers/OAuth config must be scoped to the individual server entry, never global, so one server can't read another's values.
• Preferred shape: config lists required header keys only (with required, description, etc.) — no values, no placeholders. Placeholders encourage users to paste secrets into the file. The client is responsible for prompting the user or fetching the value securely.
• Provider model: config can specify a secret provider (1password, env, OS keychain, …) + params; client resolves at runtime. Allows diverse secure backends.
• Strongest design: host-based namespacing — secrets are keyed by the server's host URI + header name, so a server can only ever retrieve values explicitly scoped to its own identity. Prevents a malicious config from grabbing arbitrary credentials.
• Baseline requirement: any standard format must make leaking secrets hard by default.

5. Protocol Release Cadence & Version Support Policy

Problem

• Supporting all past protocol versions indefinitely is corrosive tech debt, especially for large implementers (Microsoft). Current SDKs lean on forward-compat with no deprecation policy.

Proposed cadence

• 6-month cycle: ~3 months building features → ~3 months Release Candidate for SDK implementation, feedback, polish.
• Put less into each spec release + enforce a rigorous RC phase → fewer regrettable features, less partner thrash.

Support window

• Strong hesitation to commit beyond 1 year at the protocol level given how fast the agentic space moves (5 years, even 2, deemed unrealistic). Microsoft's normal GA-API bar is ~3 years but even that is shrinking for AI products.
• Model floated: 1 year supported + 1 year deprecation before removal — flagged as a possible burden on SDK maintainers.
• SDK tiering as the enforcement lever: Tier-1 SDKs must support spec versions for N years.
• Get major clients (Claude, VS Code, Gemini) to publicly agree on which versions they support → de-facto ecosystem stability.
• A committed support window (even 1 year) is an important signal for enterprise adoption; SDKs may need to commit longer than the protocol itself.

Action items: decide cadence + support duration; invite FastMCP/unofficial maintainers into the release discussions.

Cross-Cutting Themes

• Stateless-by-default, scale-out friendly — push state to client or per-request, stop assuming sticky connections.
• Transport ≠ the real problem — STDIO vs HTTP matters less than what code runs where and how it's distributed.
• Registry as the trust anchor — scanning, verified publishers, version pinning/aging, private registries.
• Secrets never in plaintext config — keys-only + provider resolution + host-namespacing.
• SDK as the DX shock absorber — wrap MTR for simple cases, tier SDKs for version support, migrate sessions via SDK v2.
• Breaking changes are coming; manage them deliberately — deprecation windows, migration guides, RC periods.
• Supply-chain attack is "when, not if" — reputational risk to MCP as a whole.

Consolidated Action Items

• Security best-practices doc for local/STDIO servers: package auditing, dependency pinning, private registries.
• Better stateless-elicitation (MTR) examples showing real state management (confirm-delete, auth prompts).
• Decide release cadence + support window; bring FastMCP and other unofficial maintainers into the loop.
• Draft client-config spec with the security model (keys-only headers, provider model, host-namespaced secrets)
• Flesh out application-level "session/context" concept, pick a name, write migration guide toward SDK v2.