Merge pull request modelcontextprotocol#548 from kurtisvg/kvg-fix-version-negotiation

fix!: require negotiated version when using HTTP

Author: bhosmer-ant

docs/specification/draft/basic/authorization.mdx

@@ -125,16 +125,7 @@ sequenceDiagram
     Note over C,M: MCP communication continues with valid token
 ```
 
-### 2.4 MCP specific headers for discovery
-
-MCP clients **SHOULD** include the `MCP-Protocol-Version: <protocol-version>` HTTP header during
-any request to the MCP server allowing the MCP server to respond based on the MCP protocol version.
-
-MCP servers **SHOULD** use the `MCP-Protocol-Version` header to determine compatibility with the MCP client.
-
-For example: `MCP-Protocol-Version: 2024-11-05`
-
-### 2.5 Dynamic Client Registration
+### 2.4 Dynamic Client Registration
 
 MCP clients and authorization servers **SHOULD** support the
 OAuth 2.0 Dynamic Client Registration Protocol [RFC7591](https://datatracker.ietf.org/doc/html/rfc7591)
@@ -157,7 +148,7 @@ these authorization servers, MCP clients will have to either:
    OAuth client themselves (e.g., through a configuration interface hosted by the
    server).
 
-### 2.6 Authorization Flow Steps
+### 2.5 Authorization Flow Steps
 
 The complete Authorization flow proceeds as follows:
 
@@ -198,9 +189,9 @@ sequenceDiagram
     Note over C,M: MCP communication continues with valid token
 ```
 
-### 2.7 Access Token Usage
+### 2.6 Access Token Usage
 
-#### 2.7.1 Token Requirements
+#### 2.6.1 Token Requirements
 
 Access token handling when making requests to MCP servers **MUST** conform to the requirements defined in
 [OAuth 2.1 Section 5 "Resource Requests"](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-5).
@@ -226,7 +217,7 @@ Host: mcp.example.com
 Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
 ```
 
-#### 2.7.2 Token Handling
+#### 2.6.2 Token Handling
 
 MCP servers, acting in their role as an OAuth 2.1 resource server, **MUST** validate access tokens as described in
 [OAuth 2.1 Section 5.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-5.2).
@@ -242,7 +233,7 @@ own resources.
 
 MCP servers **MUST NOT** accept or transit any other tokens.
 
-### 2.8 Error Handling
+### 2.7 Error Handling
 
 Servers **MUST** return appropriate HTTP status codes for authorization errors:
 

docs/specification/draft/basic/lifecycle.mdx

@@ -138,6 +138,15 @@ supports. This **SHOULD** be the _latest_ version supported by the server.
 If the client does not support the version in the server's response, it **SHOULD**
 disconnect.
 
+If using HTTP, the client **MUST** include the `MCP-Protocol-Version:
+<protocol-version>` HTTP header during any subsequent requests to the MCP
+server, allowing the MCP server to respond based on the MCP protocol version. 
+
+The protocol version sent by the client **SHOULD** be the one negotiated during [initialization](https://modelcontextprotocol.io/specification/draft/basic/lifecycle#initialization).
+
+If the server receives a request with a missing, invalid, or unsupported
+MCP-Protocol-VERSION, it **MUST** respond with `400 Bad Request`.
+For example: `MCP-Protocol-Version: 2024-11-05`
 #### Capability Negotiation
 
 Client and server capabilities establish which optional protocol features will be