fix!: require negotiated version when using HTTP

Author: kurtisvg

docs/specification/2025-03-26/basic/authorization.mdx

@@ -132,15 +132,7 @@ sequenceDiagram
     Note over C: Continue with authorization flow
 ```
 
-#### 2.3.1 Server Metadata Discovery Headers
-
-MCP clients _SHOULD_ include the header `MCP-Protocol-Version: <protocol-version>` during
-Server Metadata Discovery to allow the MCP server to respond based on the MCP protocol
-version.
-
-For example: `MCP-Protocol-Version: 2024-11-05`
-
-#### 2.3.2 Authorization Base URL
+#### 2.3.1 Authorization Base URL
 
 The authorization base URL **MUST** be determined from the MCP server URL by discarding
 any existing `path` component. For example:
@@ -154,7 +146,7 @@ If the MCP server URL is `https://api.example.com/v1/mcp`, then:
 This ensures authorization endpoints are consistently located at the root level of the
 domain hosting the MCP server, regardless of any path components in the MCP server URL.
 
-#### 2.3.3 Fallbacks for Servers without Metadata Discovery
+#### 2.3.2 Fallbacks for Servers without Metadata Discovery
 
 For servers that do not implement OAuth 2.0 Authorization Server Metadata, clients
 **MUST** use the following default endpoint paths relative to the authorization base URL

docs/specification/draft/basic/authorization.mdx

@@ -157,7 +157,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 +198,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 +226,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).

docs/specification/draft/basic/lifecycle.mdx

@@ -138,6 +138,13 @@ 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. 
+
+If the server receives a request with a missing, invalid, or unsupported
+MCP-Protocol-VERSION, it **MUST** respond with `400 Bad Request`.
+
 #### Capability Negotiation
 
 Client and server capabilities establish which optional protocol features will be