Merge branch 'main' into pr/221

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/basic/authorization.md

@@ -172,7 +172,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)
@@ -195,7 +195,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:
 
@@ -228,7 +228,7 @@ sequenceDiagram
     C->>M: API Requests with Access Token
 ```
 
-#### 2.4.1 Decision Flow Overview
+#### 2.5.1 Decision Flow Overview
 
 ```mermaid
 flowchart TD
@@ -252,9 +252,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)
@@ -280,7 +280,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).
@@ -289,7 +289,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:
 
@@ -299,7 +299,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:
 
@@ -309,22 +309,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:
 
@@ -358,7 +358,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**:
 
@@ -367,7 +367,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,7 +31,6 @@ model.
 Servers that support prompts **MUST** declare the `prompts` capability during
 [initialization]({{< ref "../basic/lifecycle#initialization" >}}):
 
-
 ```json
 {
   "capabilities": {

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
 

schema/2025-03-26/schema.json

@@ -1553,6 +1553,10 @@
                     "description": "A human-readable name for this resource.\n\nThis can be used by clients to populate UI elements.",
                     "type": "string"
                 },
+                "size": {
+                    "description": "The size of the raw resource content, in bytes (i.e., before base64 encoding or any tokenization), if known.\n\nThis can be used by Hosts to display file sizes and estimate context window usage.",
+                    "type": "integer"
+                },
                 "uri": {
                     "description": "The URI of this resource.",
                     "format": "uri",

schema/2025-03-26/schema.ts

@@ -473,6 +473,13 @@ export interface Resource {
    * Optional annotations for the client.
    */
   annotations?: Annotations;
+
+  /**
+   * The size of the raw resource content, in bytes (i.e., before base64 encoding or any tokenization), if known.
+   *
+   * This can be used by Hosts to display file sizes and estimate context window usage.
+   */
+  size?: number;
 }
 
 /**

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