RFCs for MCP

[Padarn]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

I've been trying to understand some of the design decisions as part of MCP and found a it a bit hard to find references to the discussions / issues in which the protocol was updated.

Some example questions that seem to come up a lot and would be useful to have documented design choices on:

• What are "prompts" and how are the intended to be used. The protocol / docs do capture this but it'd be useful to see discussion and detailed design choices
• Why was a raw transport layer instead of standardizing on HTTP

Is this something I'm missing (perhaps it already exists and I didn't find it), or would it be useful to have a RFC registry for changes to the protocol?

[Mehdi-Bl]

"raw transport layer instead of standardizing on HTTP:" you mean stdio, allow mainly local secure communication.
"What are "prompts" : Prompts are templates, you can for example setup a Prompte template but that need an input, Example I have one that Set the main context for project. It will ask you for the project root path and tells all the rules/tools that Sonnet should use. It's a mix about prompts you would see in libs + Jinja2 templates.

[Padarn]

Thanks @Mehdi-Bl - my request here is not specific answers to these questions, but rather whether there is going to be something like an RFC (request for comments) or EP (improvement proposal) like format for protocol changes and proposals

[Mehdi-Bl]

There is already discussion here https://github.com/orgs/modelcontextprotocol/discussions/159

[Padarn]

Right thanks. I was thinking of something closer to https://www.ietf.org/process/rfcs/

[tadasant]

The team actually just put this out: Standards Track

That should be the answer to your question.

Of course, that doesn't have a full history of initial decisions that were made like the questions you asked -- you could probably comb through some GitHub discussion and PR history to get a sense, but it may be challenging to piece together. I think the team has struck the right balance of sprinting to get something off the ground, clearly striking a chord with adoption, and is now taking steps to standardize the process around this with initiatives like the linked tracker^

[Padarn]

That should be the answer to your question.

It is! Thank you.

I don't think history is needed, it was more of a forward looking question.