Merge branch 'main' into spec/sampling-includecontext

Author: LucaButBoring

AGENTS.md

@@ -0,0 +1,37 @@
+# Model Context Protocol (MCP)
+
+This repository contains the MCP specification, documentation, and blog.
+
+## Documentation Structure
+
+- `docs/` - Mintlify site (`npm run serve:docs`)
+  - `docs/docs/` - guides and tutorials
+  - `docs/specification/` - MCP specification (more formal, versioned)
+- `blog/` - Hugo blog (`npm run serve:blog`)
+
+## Specification Versioning
+
+Specifications use **date-based versioning** (YYYY-MM-DD), not semantic versioning:
+
+- `schema/[YYYY-MM-DD]/` and `docs/specification/[YYYY-MM-DD]/` - released versions
+- `schema/draft/` and `docs/specification/draft/` - in-progress work
+
+## Schema Generation
+
+TypeScript files are the **source of truth** for the protocol schema:
+
+- Edit: `schema/[version]/schema.ts`
+- Generate JSON + docs: `npm run generate:schema`
+- This creates both `schema/[version]/schema.json` and the Schema Reference document in `docs/specification/[version]/schema.mdx`
+
+Always regenerate after editing schema files.
+
+## Useful Commands
+
+```bash
+npm run serve:docs       # Local Mintlify docs server
+npm run serve:blog       # Local Hugo blog server
+npm run generate:schema  # Generate JSON schemas + MDX from TypeScript
+npm run check:docs       # Check formatting and links
+npm run check            # Run all checks
+```

CLAUDE.md

@@ -0,0 +1 @@
+AGENTS.md

GOVERNANCE.md

@@ -0,0 +1,11 @@
+General Project Policies
+
+Model Context Protocol has been established as Model Context Protocol a Series of LF Projects, LLC. Policies applicable to Model Context Protocol and participants in Model Context Protocol, including guidelines on the usage of trademarks, are located at [https://www.lfprojects.org/policies/](https://www.lfprojects.org/policies/). Governance changes approved as per the provisions of this governance document must also be approved by LF Projects, LLC.
+
+Model Context Protocol participants acknowledge that the copyright in all new contributions will be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the project.
+
+Except as described below, all code and specification contributions to the project must be made using the Apache License, Version 2.0 (available here: [https://www.apache.org/licenses/LICENSE-2.0](https://www.apache.org/licenses/LICENSE-2.0)) (the “Project License”).
+
+All outbound code and specifications will be made available under the Project License. The Core Maintainers may approve the use of an alternative open license or licenses for inbound or outbound contributions on an exception basis.
+
+All documentation (excluding specifications) will be made available under Creative Commons Attribution 4.0 International license, available at: https://creativecommons.org/licenses/by/4.0.

MAINTAINERS.md

@@ -70,6 +70,7 @@ This document lists current maintainers in the Model Context Protocol project.
 ### Rust SDK
 
 - [Alex Hancock](https://github.com/alexhancock)
+- [Michael Bolin](https://github.com/bolinfest)
 
 ### PHP SDK
 
@@ -148,6 +149,7 @@ This document lists current maintainers in the Model Context Protocol project.
 ### Financial Services Interest Group
 
 - [Sambhav Kothari](https://github.com/sambhav)
+- [Peder Holdgaard Pedersen](https://github.com/PederHP)
 
 ### Transports Interest Group
 
@@ -166,6 +168,11 @@ This document lists current maintainers in the Model Context Protocol project.
 - [Luca Chang](https://github.com/LucaButBoring)
 - [Inna Harper](https://github.com/ihrpr)
 
+### MCP Apps Working Group
+
+- [Liad Yosef](https://github.com/liady)
+- [Ido Salomon](https://github.com/idosal)
+
 ## About This Document
 
 This document is updated by the MCP maintainers and reflects the current

blog/content/posts/2025-12-09-mcp-joins-agentic-ai-foundation.md

@@ -0,0 +1,34 @@
+---
+date: "2025-12-09T09:00:00+00:00"
+publishDate: "2025-12-09T09:00:00+00:00"
+title: "MCP joins the Agentic AI Foundation"
+author: "David Soria Parra (Lead Core Maintainer)"
+tags: ["mcp", "announcement", "linux-foundation", "aaif", "governance"]
+ShowToc: true
+---
+
+Today marks a major milestone for the Model Context Protocol. Anthropic is donating MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. MCP will become a founding project of the newly created foundation.
+
+In one year, MCP has become one of the fastest-growing and widely-adopted open-source projects in AI: Over 97 million monthly SDK downloads, 10,000 active servers and first-class client support across major AI platforms like ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code and many more.
+
+Since its inception, we've remained committed to ensuring MCP remains open and community-driven. This move formalizes that commitment—ensuring MCP's vendor-neutrality and long-term independence under the same neutral stewardship that supports Kubernetes, PyTorch, and Node.js. Anthropic's commitment to MCP is unchanged: we will continue to invest in its development, maintain core infrastructure, and actively participate in the community.
+
+## The Agentic AI Foundation
+
+MCP will be a founding project of the newly created Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg to advance open-source innovation in agentic AI.
+
+MCP joins two other founding projects: goose by Block and AGENTS.md by OpenAI as founding projects.
+
+The AAIF Governing Board will make decisions regarding strategic investments, budget allocation, member recruitment, and approval of new projects, while individual projects, such as MCP, maintain full autonomy over their technical direction and day-to-day operations.
+
+## MCP's maintainer structure stays the same
+
+For MCP little changes. The governance model we introduced earlier this year continues as is. The people making decisions about the protocol are still the maintainers who have been stewarding it, guided by community input through our SEP process.
+
+The Linux Foundation provides a neutral home and infrastructure that allows maintainers to operate independently, and will not dictate the technical direction of MCP.
+
+## Thank you
+
+To all who've adopted and contributed to MCP so far, thank you. None of this would've been possible without your contribution. From building servers to maintaining SDKs to filing issues to improving documentation to welcoming new visitors and everything in between, you've made MCP what it is today.
+
+Here's to MCP's next chapter under the Linux Foundation's stewardship.

blog/content/posts/2025-12-19-mcp-transport-future.md

@@ -0,0 +1,100 @@
+---
+date: "2025-12-19T09:00:00+00:01"
+publishDate: "2025-12-19T09:00:00+00:00"
+title: "Exploring the Future of MCP Transports"
+author: "Kurtis Van Gent (Transport WG Maintainer), Shaun Smith (Transport WG Maintainer)"
+tags: ["mcp", "governance", "transports"]
+ShowToc: true
+---
+
+When MCP first launched in November of 2024, quite a few of its users relied on local environments, connecting clients to servers over [STDIO](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#stdio). As MCP became the go-to standard for LLM integrations, community needs evolved, leading to the build-out of infrastructure around remote servers. There's now growing demand for distributed deployments that can operate at scale.
+
+The [Streamable HTTP](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#streamable-http) transport was a significant step forward, enabling remote MCP deployments and unlocking new use cases. However, as enterprise deployments scale to millions of daily requests, early adopters have encountered practical challenges that make it difficult to leverage existing infrastructure patterns. The friction of stateful connections has become a bottleneck for managed services and load balancing.
+
+Some of these challenges include:
+
+- **Infrastructure Complexity:** Load balancers and API gateways must parse full JSON-RPC payloads to route traffic, rather than using standard HTTP patterns.
+- **Scaling Friction:** Stateful connections force "sticky" routing that pins traffic to specific servers, preventing effective auto-scaling.
+- **High Barrier for Simple Tools:** Developers building simple, ephemeral tools are often required to manage complex backend storage to support basic multi-turn interactions.
+- **Ambiguous Session Scope:** There is no predictable mechanism for defining where a conversation context starts and ends across distributed systems.
+
+## Roadmap
+
+Over the past few months, the Transport Working Group has worked together with the community and MCP Core Maintainers to develop solutions to these challenges.
+
+In this post we share the roadmap for evolving the Streamable HTTP transport and invite community feedback to help shape the future of MCP transports.
+
+### A Stateless Protocol
+
+MCP was originally designed as a stateful protocol. Clients and servers maintain mutual awareness through a persistent, bidirectional channel that begins with a handshake to exchange capabilities and protocol version information. Because this state remains fixed throughout the connection, scaling requires techniques like sticky sessions or distributed session storage.
+
+We envision a future where agentic applications are stateful, but the protocol itself doesn't need to be. A stateless protocol enables scale, while still providing features to support stateful application sessions when needed.
+
+We are exploring ways to make MCP stateless by:
+
+- Replacing the [`initialize` handshake](https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle#initialization) and sending the shared information with each request and response instead.
+- Providing a `discovery` mechanism for clients to query server capabilities if they need the information early, for scenarios such as UI hydration.
+
+These changes enable a more dynamic model where clients can optimistically attempt operations and receive clear error messages if a capability is unsupported.
+
+> **NOTE:** Many SDKs already offer a _`stateless`_ option in their server transport configuration, though the behavior varies across implementations. As part of this roadmap, we'll be working to standardize what "stateless" means across all official SDKs to ensure consistent behavior.
+
+### Elevating Sessions
+
+Currently, sessions are a side effect of the transport connection. With STDIO, sessions are implicit in the process lifecycle; with Streamable HTTP, sessions are created when a server assigns an `Mcp-Session-Id` during initialization. This can lead to confusion between transport and application layer concerns.
+
+We are looking at moving sessions to the _data model layer_, making them explicit rather than implicit.
+
+This would allow MCP applications to handle sessions as part of their domain logic. We're exploring several approaches, with a cookie-like mechanism being one potential candidate to decouple session state from the transport layer.
+
+This direction mirrors standard HTTP, where the protocol itself is stateless while applications build stateful semantics using cookies, tokens, and similar mechanisms. The exact approach to session creation is still being designed, with the goal of removing existing ambiguities around what a session means in remote MCP scenarios.
+
+### Elicitations and Sampling
+
+Two MCP features are central to a few of the modern AI workflows: [Elicitations](https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation), which request human input, and [Sampling](https://modelcontextprotocol.io/specification/2025-11-25/client/sampling), which enable agentic LLM interactions.
+
+Supporting these features at scale requires rethinking the bidirectional communication pattern they rely on. Currently, when a server needs more information to complete a tool call, it suspends execution and waits for a client response, requiring it to track all outstanding requests.
+
+To address this, we're looking at designing server requests and responses to work similarly to chat APIs. The server returns the elicitation request as usual, and the client returns both the request _and_ response together. This allows the server to reconstruct the necessary state purely from the returned message, avoiding long-running state management between nodes and potentially eliminating the need for back-end storage entirely.
+
+### Update Notifications and Subscriptions
+
+MCP is dynamic by design - [tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools), [prompts](https://modelcontextprotocol.io/specification/2025-11-25/server/prompts), and [resources](https://modelcontextprotocol.io/specification/2025-11-25/server/resources) can change during operation. Today, servers send `ListChangedNotification` messages to clients as a hint to invalidate their caches.
+
+We're exploring replacing the general-purpose `GET` stream with explicit subscription streams. Clients would open dedicated streams for specific items they want to monitor, with support for multiple concurrent subscriptions. If a stream is interrupted, the client simply restarts it with no complex resumption logic.
+
+To make notifications truly optional - an optimization rather than a requirement - we're considering adding Time-To-Live (TTL) values and version identifiers (such as [ETags](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag)) to data. This would let clients make intelligent caching decisions independently of the notification stream, significantly improving reliability.
+
+### JSON-RPC Envelopes
+
+MCP uses JSON-RPC for all message envelopes, including method names and parameters. As we optimize for HTTP deployments, a common question is whether routing information should be more accessible to the underlying MCP server infrastructure.
+
+While we're keeping JSON-RPC as the message format, we're exploring ways to expose routing-critical information (such as the RPC method or tool name) via standard HTTP paths or headers. This would allow load balancers and API gateways to route traffic without parsing JSON bodies.
+
+### Server Cards
+
+Today, clients must complete a full initialization handshake just to learn basic information about an MCP server, like its capabilities or available tools. This creates friction for discovery, integration, and optimization scenarios.
+
+We're exploring the direction of introducing [MCP Server Cards](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1649): structured metadata documents that servers expose through a standardized `/.well-known/mcp.json` endpoint. Server Cards enable clients to discover server capabilities, authentication requirements, and available primitives _before_ establishing a connection. This unlocks use cases like autoconfiguration, automated discovery, static security validation, and reduced latency for UI hydration — all without requiring the full initialization sequence.
+
+### Official and Custom Transports
+
+To ensure a minimum compatibility baseline across the ecosystem, MCP will continue to support only two official transports: STDIO for local deployments and Streamable HTTP for remote deployments. This keeps the core ecosystem unified, where every MCP client and server can interoperate out of the box.
+
+We also recognize that transport and protocol changes can be disruptive. Backwards compatibility is a priority, and we'll only introduce breaking changes when strictly necessary for critical use cases.
+
+For teams with specialized requirements, the MCP Specification supports [Custom Transports](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#custom-transports), giving developers the flexibility to build alternatives that fit their needs. Our focus is on making Custom Transports easier to implement by improving SDK integration—so the community can experiment freely without fragmenting the standard.
+
+## Summary
+
+These changes reorient MCP around stateless, independent requests - without sacrificing the rich features that make it powerful. Server developers get simpler horizontal scaling with no sticky sessions or distributed stores. Clients get a more predictable architecture.
+
+For most SDK users, both on the client and server sides, the impact will be minimal - we're focused on reducing breaking changes to the absolute minimum. The shift we're outlining is architectural: simpler deployments, serverless viability for advanced MCP features, and better alignment with modern infrastructure patterns.
+
+## Next Steps
+
+Work is already underway. Our goal is to finalize the required [Spec Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines) (SEPs) in the first quarter of 2026 for inclusion in the next specification release, which is tentatively slated for June of 2026. With these changes, MCP can easily scale while keeping the ergonomics that made it successful.
+
+We want your input. Join us in the [MCP Contributors Discord server](https://modelcontextprotocol.io/community/communication#discord), or engage directly with transport-related SEPs in the [Model Context Protocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol/pulls).
+
+This roadmap is shaped by real-world feedback from developers and companies building with MCP. We're excited to collaborate with the MCP community to continuously improve the protocol and its capabilities!

blog/hugo.toml

@@ -9,6 +9,7 @@ theme = 'github.com/adityatelange/hugo-PaperMod'
 [params]
   author = "The MCP project"
   description = "Updates from the Model Context Protocol project"
+  images = ["og-image.png"]
 
   [params.homeInfoParams]
     Content = "Get the latest updates from protocol maintainers and contributors about new developments, upcoming features, and real-world MCP implementations."