A working group proposes adding a first-class protocol message for scheduled reports, arguing it is a common need. Reviewers note the behaviour can already be assembled from a tool and a resource. On the project's stated design principles, how should the proposal be read?

The principle — In a widely-adopted protocol, every addition is permanent for everyone who implements it, so the bar for adding is not usefulness but necessity.

Why the key is correct — The project states its foundational primitives explicitly: MCP provides foundational primitives: resources, tools, and prompts. And it states the consequence just as explicitly — we don't add protocol features for use cases that can be constructed from these existing building blocks. A scheduled report that a tool and a resource can already express is, by that test, out of scope for a new message. The proposal is not rejected as bad; it is redirected to the layer where it belongs.

Why the others are wrong — Demand alone does not carry a proposal past the composability test, which is applied independently of how many people want it. Nor does the protocol expect to grow into every case; that is the growth it is written to resist. And declining to add a message is not the same as declining the use case, which the reviewers have just said is already achievable.

Remember this — Ask first whether the primitives already cover it. If they do, the answer is composition, not a new message. This is the single most useful lens for reading any protocol discussion: a request that names a new message is really a request to make every implementer carry that message forever, and the reviewers' job is to find out whether the same outcome is already reachable with what everyone has already built. When it is, the proposal moves to documentation or to an extension rather than into the specification, and nothing about the use case is lost.

Sources — MCP first-party documentation.