Merge branch 'main' into fix/task-diagram-clarity

Author: LucaButBoring

docs/clients.mdx

@@ -11,6 +11,7 @@ This page provides an overview of applications that support the Model Context Pr
 
 {/* prettier-ignore-start */}
 
+
 | Client                                           | [Resources] | [Prompts] | [Tools] | [Discovery] | [Sampling] | [Roots] | [Elicitation] | [Instructions] |
 | ------------------------------------------------ | ----------- | --------- | ------- | ---------------------- | ---------- | ----- | ------------ | -------------- |
 | [5ire][5ire]                                     | ❌          | ❌        | ✅      | ❓                     | ❌         | ❌    | ❓            | ❓             |
@@ -48,7 +49,7 @@ This page provides an overview of applications that support the Model Context Pr
 | [Genkit][Genkit]                                 | ⚠️          | ✅        | ✅      | ❓                     | ❌         | ❌    | ❓            | ❓             |
 | [Glama][Glama]                                   | ✅          | ✅        | ✅      | ❓                     | ❌         | ❌    | ❓            | ❓             |
 | [Gemini CLI][Gemini CLI]                         | ❌          | ✅        | ✅      | ❓                     | ❌         | ❌    | ❓            | ❓             |
-| [GenAIScript][GenAIScript]                       | ❌          | ❌        | ✅      | ❓                     | ❌         | ❌    | ❓            | ❓             |
+| [GenAIScript][GenAIScript]                       | ✅          | ❌        | ✅      | ❓                     | ❌         | ❌    | ❓            | ❓             |
 | [GitHub Copilot coding agent][GitHubCopilotCodingAgent]                       | ❌          | ❌        | ✅      | ❌                     | ❌         | ❌    | ❌            | ❓             |
 | [goose][goose]                                   | ✅          | ✅        | ✅      | ❌                     | ✅         | ❌    | ❌            | ✅             |
 | [gptme][gptme]                                   | ❌          | ❌        | ✅      | ❓                     | ❌         | ❌    | ❓            | ❓             |

docs/specification/draft/basic/authorization.mdx

@@ -203,6 +203,13 @@ MCP supports three client registration mechanisms. Choose based on your scenario
 - **Pre-registration**: When client and server have an existing relationship
 - **Dynamic Client Registration**: For backwards compatibility or specific requirements
 
+Clients supporting all options **SHOULD** follow the following priority order:
+
+1. Use pre-registered client information for the server if the client has it available
+2. Use Client ID Metadata Documents if the Authorization Server indicates if the server supports it (via `client_id_metadata_document_supported` in OAuth Authorization Server Metadata)
+3. Use Dynamic Client Registration as a fallback if the Authorization Server supports it (via `registration_endpoint` in OAuth Authorization Server Metadata)
+4. Prompt the user if no other option is available
+
 ### Client ID Metadata Documents
 
 MCP clients and authorization servers **SHOULD** support OAuth Client ID Metadata Documents as specified in
@@ -630,21 +637,8 @@ The authorization server takes a URL as input from an unknown client and fetches
 A malicious client could use this to trigger the authorization server to make requests to arbitrary URLs,
 such as requests to private administration endpoints the authorization server has access to.
 
-Authorization servers fetching metadata documents **MUST** protect against
-[Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/docs/Web/Security/Attacks/SSRF) attacks,
-as well as against being used as Denial of Service (DoS) amplifiers:
-
-- Validate URLs and resolved IP addresses before fetching
-- Limit response size (recommended 5 kilobytes)
-- Implement request timeouts
-- Implement aggressive caching of metadata documents (respecting HTTP cache headers)
-- Never cache error responses or invalid documents
-- Rate limit metadata fetch requests per client
-- Monitor and alert on unusual metadata fetch patterns
-- Only fetch client metadata after authenticating the user
-
-While there is no amplification in the fetch request bandwidth, aggressive caching minimizes
-the risk of authorization servers being used in distributed denial of service attacks.
+Authorization servers fetching metadata documents **SHOULD** consider
+[Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/docs/Web/Security/Attacks/SSRF) risks, as described in [OAuth Client ID Metadata Document: Server Side Request Forgery (SSRF) Attacks](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00#name-server-side-request-forgery).
 
 #### Localhost Redirect URI Risks
 

docs/specification/draft/basic/transports.mdx

@@ -111,7 +111,7 @@ MCP endpoint.
      at any time in order to avoid holding a long-lived connection. The client
      **SHOULD** then "poll" the SSE stream by attempting to reconnect.
    - If the server does close the _connection_ prior to terminating the _SSE stream_,
-     it **SHOULD** send an SSE event with a standard `retry` field before
+     it **SHOULD** send an SSE event with a standard [`retry`](https://html.spec.whatwg.org/multipage/server-sent-events.html#the-retry-value) field before
      closing the connection. The client **MUST** respect the `retry` field,
      waiting the given number of milliseconds before attempting to reconnect.
    - The SSE stream **SHOULD** eventually include a JSON-RPC _response_ for the
@@ -148,6 +148,9 @@ MCP endpoint.
      [resuming](#resumability-and-redelivery) a stream associated with a previous client
      request.
    - The server **MAY** close the SSE stream at any time.
+   - If the server closes the _connection_ without terminating the _stream_, it
+     **SHOULD** follow the same polling behavior as described for POST requests:
+     sending a `retry` field and allowing the client to reconnect.
    - The client **MAY** close the SSE stream at any time.
 
 ### Multiple Connections
@@ -168,15 +171,20 @@ lost:
    - If present, the ID **MUST** be globally unique across all streams within that
      [session](#session-management)—or all streams with that specific client, if session
      management is not in use.
-2. If the client wishes to resume after a broken connection, it **SHOULD** issue an HTTP
-   GET to the MCP endpoint, and include the
+   - Event IDs **SHOULD** encode sufficient information to identify the originating
+     stream, enabling the server to correlate a `Last-Event-ID` to the correct stream.
+2. If the client wishes to resume after a disconnection (whether due to network failure
+   or server-initiated closure), it **SHOULD** issue an HTTP GET to the MCP endpoint,
+   and include the
    [`Last-Event-ID`](https://html.spec.whatwg.org/multipage/server-sent-events.html#the-last-event-id-header)
    header to indicate the last event ID it received.
    - The server **MAY** use this header to replay messages that would have been sent
      after the last event ID, _on the stream that was disconnected_, and to resume the
      stream from that point.
    - The server **MUST NOT** replay messages that would have been delivered on a
      different stream.
+   - This mechanism applies regardless of how the original stream was initiated (via
+     POST or GET). Resumption is always via HTTP GET with `Last-Event-ID`.
 
 In other words, these event IDs should be assigned by servers on a _per-stream_ basis, to
 act as a cursor within that particular stream.
@@ -291,8 +299,8 @@ protocol version 2024-11-05) as follows:
    defined above:
    - If it succeeds, the client can assume this is a server supporting the new Streamable
      HTTP transport.
-   - If it fails with an HTTP 4xx status code (e.g., 405 Method Not Allowed or 404 Not
-     Found):
+   - If it fails with the following HTTP status codes "400 Bad Request", "404 Not
+     Found" or "405 Method Not Allowed":
      - Issue a GET request to the server URL, expecting that this will open an SSE stream
        and return an `endpoint` event as the first event.
      - When the `endpoint` event arrives, the client can assume this is a server running

docs/specification/draft/changelog.mdx

@@ -26,11 +26,22 @@ the previous revision, [2025-06-18](/specification/2025-06-18).
 3. Updated the [Security Best Practices guidance](https://modelcontextprotocol.io/specification/draft/basic/security_best_practices).
 4. Clarify that input validation errors should be returned as Tool Execution Errors rather than Protocol Errors to enable model self-correction ([SEP-1303](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1303)).
 5. Support polling SSE streams by allowing servers to disconnect at will ([SEP-1699](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1699)).
+6. Clarify SEP-1699: GET streams support polling, resumption always via GET regardless of stream origin, event IDs should encode stream identity, disconnection includes server-initiated closure (Issue [#1847](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1847)).
+7. Align OAuth 2.0 Protected Resource Metadata discovery with RFC 9728, making `WWW-Authenticate` header optional with fallback to `.well-known` endpoint ([SEP-985](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/985)).
+8. Add support for default values in all primitive types (string, number, enum) for elicitation schemas ([SEP-1034](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1034)).
+9. Establish JSON Schema 2020-12 as the default dialect for MCP schema definitions ([SEP-1613](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1613)).
 
 ## Other schema changes
 
 1. Decouple request payloads from RPC method definitions into standalone parameter schemas. ([SEP-1319](https://github.com/modelcontextprotocol/specification/issues/1319), PR [#1284](https://github.com/modelcontextprotocol/specification/pull/1284))
 
+## Governance and process updates
+
+1. Formalize Model Context Protocol governance structure ([SEP-932](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/932)).
+2. Establish shared communication practices and guidelines for the MCP community ([SEP-994](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/994)).
+3. Formalize Working Groups and Interest Groups in MCP governance ([SEP-1302](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1302)).
+4. Establish SDK tiering system with clear requirements for feature support and maintenance commitments ([SEP-1730](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1730)).
+
 ## Full changelog
 
 For a complete list of all changes that have been made since the last protocol revision,