Follow Discord
Sweep 22 Oct 2026 · 21:04Z Build v2.1.309 528 read Stable v2.1.308 Latest v2.1.309 Next v2.1.309 Feeds RSS JSON llms.txt llms-full.txt Unofficial
One change · mcp

Design Principles changedcommunity/design-principles

Upstream edited this page at 28 Jul 2026 15:42 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 22 Oct 2026 20:37 UTC.

Upstream edited
Recorded here
Lines+4added
Lines−4removed
From line 2 where the diff opens
First seen 14 Aug 2026 this site's first read of the page
Recorded edits2to this page, all time

The whole hunk

from line 2, old and new numbered
/
lines
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](/community/sep-guidelines) (SEPs) and [extensions](/extensions/overview).
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](/community/sep-guidelines.md) (SEPs) and [extensions](/extensions/overview.md).
66 
77## Convergence over choice
88 
99There 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 
11[Extensions](/extensions/overview) are where convergence gets tested; the specification is where it gets committed.
11[Extensions](/extensions/overview.md) are where convergence gets tested; the specification is where it gets committed.
1212 
1313## Composability over specificity
1414 
1515MCP 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.
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](/extensions/apps/overview) and [Tasks](/extensions/tasks/overview) capture the patterns that emerge.
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](/extensions/apps/overview.md) and [Tasks](/extensions/tasks/overview.md) capture the patterns that emerge.
1818 
1919## Interoperability over optimization
2020 
from line 44
4444 
4545MCP 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.
4646 
47We encourage the use of [MCP extensions](/extensions/overview) as a way to experiment with new patterns that may eventually lead to standardization.
47We encourage the use of [MCP extensions](/extensions/overview.md) as a way to experiment with new patterns that may eventually lead to standardization.
4848 
Feedback