Design Principles changedcommunity/design-principles
Nearest release: v2.1.321, published 5 hours after upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 9 Nov 2026 13:29 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 9 Nov 2026 13:37 UTC.
Upstream edited
Recorded here
Lines+7added
Lines−13removed
From line
2
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits4to this page, all time
The whole hunk
from line 2, old and new numbered
/
from line 2
22
33> The core design principles that guide the development of the Model Context Protocol.
44
5These 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](https://modelcontextprotocol.io/community/sep-guidelines.md) (SEPs) and [extensions](https://modelcontextprotocol.io/extensions/overview.md).
5These principles guide how we evaluate protocol proposals, weigh tradeoffs, and evolve MCP. They apply to [Specification Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines.md) (SEPs) and [extensions](https://modelcontextprotocol.io/extensions/overview.md), and are distinct from the specification's [architectural design principles](https://modelcontextprotocol.io/specification/latest/architecture.md#design-principles), which describe how servers and clients are built. Core Maintainers cite them when accepting or rejecting SEPs. A proposal that cuts against a principle should say so and argue why. When two principles conflict, they are weighed against each other, not ranked.
66
77## Convergence over choice
88
9There 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.
9There 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.
1010
1111[Extensions](https://modelcontextprotocol.io/extensions/overview.md) are where convergence gets tested; the specification is where it gets committed.
1212
1313## Composability over specificity
1414
15MCP provides foundational primitives: resources, tools, and prompts. 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.
15MCP provides foundational primitives: resources, tools, and prompts. 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. Extensions like [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview.md) and [Tasks](https://modelcontextprotocol.io/extensions/tasks/overview.md) capture the patterns that emerge.
1616
17When 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](https://modelcontextprotocol.io/extensions/apps/overview.md) and [Tasks](https://modelcontextprotocol.io/extensions/tasks/overview.md) capture the patterns that emerge.
18
1917## Interoperability over optimization
2018
2119MCP 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.
from line 20
2220
2321## Stability over velocity
2422
25Adding 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.
23Adding 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. We optimize for decades, not quarters. Removal, when it happens, follows [Feature Lifecycle and Deprecation](https://modelcontextprotocol.io/community/feature-lifecycle.md).
2624
27Contributors accustomed to rapid shipping may find this pace frustrating, but sustainable standards require sustainable decision-making. We optimize for decades, not quarters.
28
2925## Capability over compensation
3026
31Models 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.
27Models 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.
3228
3329This 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.
3430
3531## Demonstration over deliberation
3632
37MCP 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.
33MCP values working implementations over theoretical debates, and evidence from real usage over hypothetical arguments. We encourage contributors to prototype rather than design by committee. A SEP needs a working [prototype](https://modelcontextprotocol.io/community/sep-guidelines.md#prototype-requirements) before it can be accepted.
3834
3935## Pragmatism over purity
4036
from line 38
4238
4339## Standardization over innovation
4440
45MCP 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.
46
47We encourage the use of [MCP extensions](https://modelcontextprotocol.io/extensions/overview.md) as a way to experiment with new patterns that may eventually lead to standardization.
41MCP 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. New patterns are best tried in [extensions](https://modelcontextprotocol.io/extensions/overview.md) first.
4842
No line in this hunk matches that.