A compliance checklist must record which MCP protocol revision a deployment targets, written in the same form that requests use for their protocol version metadata. Which kind of value should be recorded?
Select an answer to reveal the explanation.
Short Explanation
MCP versions read like a calendar, not like software releases. You'll see 2026-07-28 in every request's _meta and in the MCP-Protocol-Version header, so that's the form your checklist wants. Semantic-version thinking is the trap here.
Full Explanation
MCP identifies each specification revision by a date string. Revision 2026-07-28 is carried in every request's io.modelcontextprotocol/protocolVersion _meta field and, on Streamable HTTP, mirrored in the MCP-Protocol-Version header; earlier revisions are likewise named 2025-11-25, 2025-06-18, 2025-03-26 and 2024-11-05. Recording the same date string lets an auditor match the checklist directly against traffic and server/discover results, whose supportedVersions list uses the same form. A semantic version number is not how MCP labels revisions, and inventing one would fail to match anything on the wire. Codenames are not used to identify revisions in the protocol, so a name would not correspond to any field a client or server exchanges. An SDK build number identifies a library release, not the protocol revision, and several SDK releases can implement the same revision. Exam caveat: SDK packages do carry their own version numbers, so stems that mix SDK releases with protocol revisions are testing whether you keep the two apart. Operational check: capture a request or a server/discover result from the deployment and confirm that the recorded value exactly matches the protocol version it declares and the server lists as supported.