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
/
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
No line in this hunk matches that.