Merge branch 'main' into pr/239

Author: jspahrsummers

README.md

@@ -2,8 +2,8 @@
 
 This repo contains the specification and protocol schema for the Model Context Protocol.
 
-The schema is [defined in TypeScript](schema/2024-11-05/schema.ts) first, but
-[made available as JSON Schema](schema/2024-11-05/schema.json) as well, for wider
+The schema is [defined in TypeScript](schema/2025-03-26/schema.ts) first, but
+[made available as JSON Schema](schema/2025-03-26/schema.json) as well, for wider
 compatibility.
 
 ## Contributing

docs/specification/2024-11-05/server/utilities/pagination.md

@@ -17,7 +17,8 @@ data sets.
 Pagination in MCP uses an opaque cursor-based approach, instead of numbered pages.
 
 - The **cursor** is an opaque string token, representing a position in the result set
-- **Page size** is determined by the server, and **MAY NOT** be fixed
+- **Page size** is determined by the server, and clients **MUST NOT** assume a fixed page
+  size
 
 ## Response Format
 

docs/specification/2025-03-26/_index.md

@@ -19,7 +19,7 @@ they need.
 
 This specification defines the authoritative protocol requirements, based on the
 TypeScript schema in
-[schema.ts](https://github.com/modelcontextprotocol/specification/blob/main/schema/draft/schema.ts).
+[schema.ts](https://github.com/modelcontextprotocol/specification/blob/main/schema/2025-03-26/schema.ts).
 
 For implementation guides and examples, visit
 [modelcontextprotocol.io](https://modelcontextprotocol.io).

docs/specification/2025-03-26/basic/_index.md

@@ -119,10 +119,10 @@ to help shape the future of the protocol!
 ## Schema
 
 The full specification of the protocol is defined as a
-[TypeScript schema](http://github.com/modelcontextprotocol/specification/tree/main/schema/draft/schema.ts).
+[TypeScript schema](https://github.com/modelcontextprotocol/specification/blob/main/schema/2025-03-26/schema.ts).
 This is the source of truth for all protocol messages and structures.
 
 There is also a
-[JSON Schema](http://github.com/modelcontextprotocol/specification/tree/main/schema/draft/schema.json),
+[JSON Schema](https://github.com/modelcontextprotocol/specification/blob/main/schema/2025-03-26/schema.json),
 which is automatically generated from the TypeScript source of truth, for use with
 various automated tooling.

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

@@ -155,7 +155,7 @@ Clients **MUST** first attempt to discover endpoints via the metadata document b
 falling back to default paths. When using default paths, all other protocol requirements
 remain unchanged.
 
-### 2.3 Dynamic Client Registration
+### 2.4 Dynamic Client Registration
 
 MCP clients and servers **SHOULD** support the
 [OAuth 2.0 Dynamic Client Registration Protocol](https://datatracker.ietf.org/doc/html/rfc7591)
@@ -178,7 +178,7 @@ these servers, MCP clients will have to either:
    OAuth client themselves (e.g., through a configuration interface hosted by the
    server).
 
-### 2.4 Authorization Flow Steps
+### 2.5 Authorization Flow Steps
 
 The complete Authorization flow proceeds as follows:
 
@@ -211,7 +211,7 @@ sequenceDiagram
     C->>M: API Requests with Access Token
 ```
 
-#### 2.4.1 Decision Flow Overview
+#### 2.5.1 Decision Flow Overview
 
 ```mermaid
 flowchart TD
@@ -235,9 +235,9 @@ flowchart TD
     N --> O[Use Access Token]
 ```
 
-### 2.5 Access Token Usage
+### 2.6 Access Token Usage
 
-#### 2.5.1 Token Requirements
+#### 2.6.1 Token Requirements
 
 Access token handling **MUST** conform to
 [OAuth 2.1 Section 5](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-5)
@@ -263,7 +263,7 @@ Host: mcp.example.com
 Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
 ```
 
-#### 2.5.2 Token Handling
+#### 2.6.2 Token Handling
 
 Resource servers **MUST** validate access tokens as described in
 [Section 5.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-5.2).
@@ -272,7 +272,7 @@ If validation fails, servers **MUST** respond according to
 error handling requirements. Invalid or expired tokens **MUST** receive a HTTP 401
 response.
 
-### 2.6 Security Considerations
+### 2.7 Security Considerations
 
 The following security requirements **MUST** be implemented:
 
@@ -282,7 +282,7 @@ The following security requirements **MUST** be implemented:
 4. Servers **MUST** validate redirect URIs to prevent open redirect vulnerabilities
 5. Redirect URIs **MUST** be either localhost URLs or HTTPS URLs
 
-### 2.7 Error Handling
+### 2.8 Error Handling
 
 Servers **MUST** return appropriate HTTP status codes for authorization errors:
 
@@ -292,22 +292,22 @@ Servers **MUST** return appropriate HTTP status codes for authorization errors:
 | 403         | Forbidden    | Invalid scopes or insufficient permissions |
 | 400         | Bad Request  | Malformed authorization request            |
 
-### 2.8 Implementation Requirements
+### 2.9 Implementation Requirements
 
 1. Implementations **MUST** follow OAuth 2.1 security best practices
 2. PKCE is **REQUIRED** for all clients
 3. Token rotation **SHOULD** be implemented for enhanced security
 4. Token lifetimes **SHOULD** be limited based on security requirements
 
-### 2.9 Third-Party Authorization Flow
+### 2.10 Third-Party Authorization Flow
 
-#### 2.9.1 Overview
+#### 2.10.1 Overview
 
 MCP servers **MAY** support delegated authorization through third-party authorization
 servers. In this flow, the MCP server acts as both an OAuth client (to the third-party
 auth server) and an OAuth authorization server (to the MCP client).
 
-#### 2.9.2 Flow Description
+#### 2.10.2 Flow Description
 
 The third-party authorization flow comprises these steps:
 
@@ -341,7 +341,7 @@ sequenceDiagram
     M->>C: MCP access token
 ```
 
-#### 2.9.3 Session Binding Requirements
+#### 2.10.3 Session Binding Requirements
 
 MCP servers implementing third-party authorization **MUST**:
 
@@ -350,7 +350,7 @@ MCP servers implementing third-party authorization **MUST**:
 3. Implement appropriate token lifecycle management
 4. Handle third-party token expiration and renewal
 
-#### 2.9.4 Security Considerations
+#### 2.10.4 Security Considerations
 
 When implementing third-party authorization, servers **MUST**:
 

docs/specification/2025-03-26/server/prompts.md

@@ -31,9 +31,15 @@ model.
 Servers that support prompts **MUST** declare the `prompts` capability during
 [initialization]({{< ref "../basic/lifecycle#initialization" >}}):
 
-/draft`json { "capabilities": { "prompts": { "listChanged": true } } }
-
-````
+```json
+{
+  "capabilities": {
+    "prompts": {
+      "listChanged": true
+    }
+  }
+}
+```
 
 `listChanged` indicates whether the server will emit notifications when the list of
 available prompts changes.
@@ -56,7 +62,7 @@ supports [pagination]({{< ref "utilities/pagination" >}}).
     "cursor": "optional-cursor-value"
   }
 }
-````
+```
 
 **Response:**
 

docs/specification/2025-03-26/server/utilities/pagination.md

@@ -17,7 +17,8 @@ data sets.
 Pagination in MCP uses an opaque cursor-based approach, instead of numbered pages.
 
 - The **cursor** is an opaque string token, representing a position in the result set
-- **Page size** is determined by the server, and **MAY NOT** be fixed
+- **Page size** is determined by the server, and clients **MUST NOT** assume a fixed page
+  size
 
 ## Response Format
 

site/hugo.yaml

@@ -95,3 +95,15 @@ menu:
       name: "TypeScript SDK ↗"
       url: "https://github.com/modelcontextprotocol/typescript-sdk"
       weight: 5
+    - identifier: javaSdk
+      name: "Java SDK ↗"
+      url: "https://github.com/modelcontextprotocol/java-sdk"
+      weight: 6
+    - identifier: kotlinSdk
+      name: "Kotlin SDK ↗"
+      url: "https://github.com/modelcontextprotocol/kotlin-sdk"
+      weight: 7
+    - identifier: csharpSdk
+      name: "C# SDK ↗"
+      url: "https://github.com/modelcontextprotocol/csharp-sdk"
+      weight: 8