Validate MCP-Protocol-Version header in Streamable HTTP handler

[Copilot]

• Add MCP-Protocol-Version header validation in StreamableHttpHandler.cs for POST, GET, and DELETE handlers
• Add tests in StreamableHttpServerConformanceTests.cs
• Add SupportedProtocolVersions as an abstract instance property on McpServer (not McpSession — only relevant to servers)
• Implement in McpServerImpl (delegates to McpSessionHandler.SupportedProtocolVersions) and DestinationBoundMcpServer
• Move validation after session resolution in handler, querying the server instance
• Fix DELETE handler to validate before removing session
• Change SupportedProtocolVersions from ICollection<string> to IReadOnlyList<string>

Original prompt

---

This section details on the original issue you should resolve

<issue_title>The server should validate the MCP-Protocol-Version header value</issue_title>
<issue_description>Describe the bug

The 2025-06-18 version of the MCP spec added this requirement on clients:

If using HTTP, the client MUST include the MCP-Protocol-Version: HTTP header on all subsequent requests to the MCP server

The MCP Server framework in the C# SDK does not verify that the client has provided the MCP-Protocol-Version header, and if it was specified, does not verify that it matches the negotiated protocol version for the session or even if it is a valid protocol version.

To Reproduce

Start a session with the new protocol version 2025-06-18. Then send a "tools/list" request that omits the MCP-Protocol-Version header, or with an MCP-Protocol-Version header with a bogus value.

Expected behavior

If the Streaming HTTP session is using protocol version 2025-06-18, a request without an MCP-Protocol-Version header should be rejected, or at the very least generate a warning log message.

If an MCP-Protocol-Version header is provided, the server should verify that a) the value is a valid / known protocol version, and b) it matches the protocol version negotiated for the session, and fail the request if either of these conditions are not satisfied.

Additional context

The ProtocolVersion project in the v0.3.0 branch of this repo, with a few small modifications, can be used to reproduce this problem.

</issue_description>

<agent_instructions>Please ensure this part is appropriately handled in the implementation and tests:

"If the server receives a request with an invalid or unsupported MCP-Protocol-Version, it MUST respond with 400 Bad Request.

So it's an error to have an invalid header but not an error to not have the header at all." </agent_instructions>

Comments on the Issue (you are @copilot in this section)

@stephentoub > If the Streaming HTTP session is using protocol version 2025-06-18, a request without an MCP-Protocol-Version header should be rejected

The spec states:

For backwards compatibility, if the server does not receive an MCP-Protocol-Version header, and has no other way to identify the version - for example, by relying on the protocol version negotiated during initialization - the server SHOULD assume protocol version 2025-06-18.

If the server receives a request with an invalid or unsupported MCP-Protocol-Version, it MUST respond with 400 Bad Request.

So it's an error to have an invalid header but not an error to not have the header at all.</comment_new>
<comment_new>@mikekistler
If the protocol version was negotiated during initialization to be 2025-06-18, wouldn't it be the case that the server has a way to identify the version for the session?</comment_new>
<comment_new>@stephentoub

If the protocol version was negotiated during initialization to be 2025-06-18, wouldn't it be the case that the server has a way to identify the version for the session?

Yes</comment_new>

• Fixes The server should validate the MCP-Protocol-Version header value #540

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.