设计原则

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 (SEPs) and extensions.

​

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 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 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 as a way to experiment with new patterns that may eventually lead to standardization.