docs: add design principles page to community section (modelcontextprotocol#2303)

* docs: add design principles page to community section

- Create docs/community/design-principles.mdx with six core design
  principles: convergence, composability, stability, demonstration,
  pragmatism, and standardization
- Add 'Principles & Direction' navigation group to the Community tab
  in docs.json, positioned before Governance
- This group will later house values and priorities pages

* Update docs/community/design-principles.mdx

Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>

* Update docs/community/design-principles.mdx

Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>

* Update docs/community/design-principles.mdx

Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>

* Update docs/community/design-principles.mdx

Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>

* Update docs/community/design-principles.mdx

Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>

* Update design-principles.mdx

Co-authored-by: Den Delimarsky <53200638+localden@users.noreply.github.com>

* Update design-principles.mdx

Co-authored-by: Den Delimarsky <53200638+localden@users.noreply.github.com>

* Update design-principles.mdx

Co-authored-by: Den Delimarsky <53200638+localden@users.noreply.github.com>

* Update design-principles.mdx

Co-authored-by: Den Delimarsky <53200638+localden@users.noreply.github.com>

* Update design-principles.mdx

Co-authored-by: Den Delimarsky <53200638+localden@users.noreply.github.com>

* Update design-principles.mdx

Co-authored-by: Den Delimarsky <53200638+localden@users.noreply.github.com>

* Update design-principles.mdx

Co-authored-by: Den Delimarsky <53200638+localden@users.noreply.github.com>

* Link to design principles from SEP guidelines

* Update docs/community/design-principles.mdx

Co-authored-by: Den Delimarsky <53200638+localden@users.noreply.github.com>

* docs: add two principles and tighten Convergence section

Add "Interoperability over optimization" and "Capability over
compensation" based on PR discussion with pja-ant and olaservo.
The first captures graceful degradation via capability negotiation;
the second addresses not encoding temporary model limitations into
permanent protocol structure, with olaservo's refinement that
optional semantic richness costing nothing is fine.

Also rework the Convergence over choice opener to stop restating
its own heading, and tighten the extensions sentence.

---------

Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
Co-authored-by: Den Delimarsky <53200638+localden@users.noreply.github.com>
Co-authored-by: David Soria Parra <14013+dsp@users.noreply.github.com>

Author: 4 people

docs/community/design-principles.mdx

@@ -0,0 +1,48 @@
+---
+title: Design Principles
+description: The core design principles that guide the development of the Model Context Protocol.
+---
+
+These principles guide how we evaluate protocol proposals, weigh tradeoffs, and evolve MCP. They reflect lessons from building and maintaining the project. They are meant as guidance by and for the community when developing [Spec Enhancement Proposals](/community/sep-guidelines) (SEPs) and [extensions](/extensions/overview).
+
+## Convergence over choice
+
+There should be one way to solve a problem in MCP. Rather than supporting multiple approaches that fragment the ecosystem, we choose a single well-designed path — accepting harder decisions upfront to deliver a more cohesive protocol.
+
+[Extensions](/extensions/overview) are where convergence gets tested; the specification is where it gets committed.
+
+## Composability over specificity
+
+MCP provides foundational primitives: resources, tools, prompts, and tasks. We don't add protocol features for use cases that can be constructed from these existing building blocks. This keeps the surface area small and implementations simple.
+
+When someone asks why MCP doesn't support a feature directly, the answer is usually that it can be built from what MCP already provides. Extensions like [MCP Apps](/extensions/apps/overview) capture the patterns that emerge.
+
+## Interoperability over optimization
+
+MCP runs across clients, servers, and models of widely varying sophistication. We favor features that degrade gracefully over those that only work when every participant is equally capable. Capability negotiation makes this concrete: participants declare what they support, and the protocol adapts rather than assumes.
+
+## Stability over velocity
+
+Adding to a protocol as widely adopted as MCP is easy. Removing from it is nearly impossible. Every addition is a permanent commitment and a cost for client implementers to support. We move deliberately, knowing that "no" today leaves the door open while "yes" closes it forever.
+
+Contributors accustomed to rapid shipping may find this pace frustrating, but sustainable standards require sustainable decision-making. We optimize for decades, not quarters.
+
+## Capability over compensation
+
+Models improve faster than protocols evolve. We avoid adding permanent structure to work around limitations that are likely temporary — the limitation fades, but the complexity remains.
+
+This is not license to ignore today's reality. Optional context that weaker models lean on and stronger ones ignore costs nothing. But when a proposal exists primarily because current models struggle without it, we ask whether they will outgrow the need before we can shed the weight.
+
+## Demonstration over deliberation
+
+MCP values working implementations over theoretical debates. When evaluating proposals, we prioritize evidence from real usage over hypothetical arguments. We encourage contributors to prototype, experiment, and demonstrate rather than design by committee. Implementation reveals what discussion cannot.
+
+## Pragmatism over purity
+
+MCP makes practical tradeoffs in service of adoption and usability. We don't pursue theoretical elegance at the cost of real-world utility. When a "correct" design creates friction for implementers, we consider whether a "good enough" design better serves the ecosystem. This means accepting some inconsistency, some historical accidents, and some decisions we might make differently with hindsight.
+
+## Standardization over innovation
+
+MCP standardizes patterns that have already proven valuable. We look for conventions that work across multiple implementations and codify them, rather than inventing new paradigms and hoping they'll be adopted.
+
+We encourage the use of [MCP extensions](/extensions/overview) as a way to experiment with new patterns that may eventually lead to standardization.

docs/community/sep-guidelines.mdx

@@ -9,6 +9,8 @@ SEP stands for Specification Enhancement Proposal. A SEP is a design document pr
 
 SEPs are the primary mechanism for proposing major new features, collecting community input on an issue, and documenting the design decisions that have gone into MCP. The SEP author is responsible for building consensus within the community and documenting dissenting opinions.
 
+When drafting a SEP, authors should review the [MCP design principles](/community/design-principles), which outline the core values and tradeoffs that guide the protocol's evolution.
+
 SEPs are maintained as markdown files in the [`seps/` directory](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps) of the specification repository. Their revision history serves as the historical record of the feature proposal.
 
 ## When to Write a SEP

docs/docs.json

@@ -375,6 +375,12 @@
         "pages": [
           "community/contributing",
           "community/communication",
+          {
+            "group": "Principles & Direction",
+            "pages": [
+              "community/design-principles"
+            ]
+          },
           {
             "group": "Governance",
             "pages": [