Merge branch 'main' into patch-1

Author: DSchau

docs/clients.mdx

@@ -122,6 +122,7 @@ To use an MCP server with Claude, add it to your configuration:
 - [Awesome MCP Servers](https://github.com/punkpeye/awesome-mcp-servers) - Curated list of MCP servers
 - [MCP CLI](https://github.com/wong2/mcp-cli) - Command-line inspector for testing MCP servers
 - [MCP Get](https://mcp-get.com) - Tool for installing and managing MCP servers
+- [Pipedream MCP](https://mcp.pipedream.com) - MCP servers with built-in auth for 3,000+ APIs and 10,000+ tools
 - [Supergateway](https://github.com/supercorp-ai/supergateway) - Run MCP stdio servers over SSE
 - [Zapier MCP](https://zapier.com/mcp) - MCP Server with over 7,000+ apps and 30,000+ actions
 

docs/examples.mdx

@@ -39,6 +39,9 @@ source .venv/bin/activate
 uv add mcp anthropic python-dotenv
 
 # Remove boilerplate files
+# On Windows:
+del main.py
+# On Unix or MacOS:
 rm main.py
 
 # Create our main file

docs/quickstart/client.mdx

@@ -82,14 +82,18 @@ authorization servers to MCP clients, as well as the discovery process through w
 clients can determine authorization server endpoints and supported capabilities.
 
 ### 2.3.1 Authorization Server Location
+
 MCP servers **MUST** implement OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728))
 specification to indicate the locations of authorization servers. The Protected Resource Metadata document returned by the MCP server **MUST** include
 the `authorization_servers` field containing at least one authorization server.
 
 The specific use of `authorization_servers` is beyond the scope of this specification; implementers should consult
- OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728)) for
+OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728)) for
 guidance on implementation details.
 
+Implementors should note that Protected Resource Metadata documents can define multiple authorization servers. The responsibility for selecting which authorization server to use lies with the MCP client, following the guidelines specified in
+[RFC9728 Section 7.6 "Authorization Servers"](https://datatracker.ietf.org/doc/html/rfc9728#name-authorization-servers).
+
 MCP servers **MUST** use the HTTP header `WWW-Authenticate` when returning a _401 Unauthorized_ to indicate the location of the resource server metadata URL
 as described in OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728)).
 

docs/specification/draft/basic/authorization.mdx

@@ -24,9 +24,7 @@ In the **stdio** transport:
 - The client launches the MCP server as a subprocess.
 - The server reads JSON-RPC messages from its standard input (`stdin`) and sends messages
   to its standard output (`stdout`).
-- Messages may be JSON-RPC requests, notifications, responses—or a JSON-RPC
-  [batch](https://www.jsonrpc.org/specification#batch) containing one or more requests
-  and/or notifications.
+- Messages are individual JSON-RPC requests, notifications, or responses.
 - Messages are delimited by newlines, and **MUST NOT** contain embedded newlines.
 - The server **MAY** write UTF-8 strings to its standard error (`stderr`) for logging
   purposes. Clients **MAY** capture, forward, or ignore this logging.
@@ -85,35 +83,27 @@ MCP endpoint.
 1. The client **MUST** use HTTP POST to send JSON-RPC messages to the MCP endpoint.
 2. The client **MUST** include an `Accept` header, listing both `application/json` and
    `text/event-stream` as supported content types.
-3. The body of the POST request **MUST** be one of the following:
-   - A single JSON-RPC _request_, _notification_, or _response_
-   - An array [batching](https://www.jsonrpc.org/specification#batch) one or more
-     _requests and/or notifications_
-   - An array [batching](https://www.jsonrpc.org/specification#batch) one or more
-     _responses_
-4. If the input consists solely of (any number of) JSON-RPC _responses_ or
-   _notifications_:
+3. The body of the POST request **MUST** be a single JSON-RPC _request_, _notification_, or _response_.
+4. If the input is a JSON-RPC _response_ or _notification_:
    - If the server accepts the input, the server **MUST** return HTTP status code 202
      Accepted with no body.
    - If the server cannot accept the input, it **MUST** return an HTTP error status code
      (e.g., 400 Bad Request). The HTTP response body **MAY** comprise a JSON-RPC _error
      response_ that has no `id`.
-5. If the input contains any number of JSON-RPC _requests_, the server **MUST** either
+5. If the input is a JSON-RPC _request_, the server **MUST** either
    return `Content-Type: text/event-stream`, to initiate an SSE stream, or
    `Content-Type: application/json`, to return one JSON object. The client **MUST**
    support both these cases.
 6. If the server initiates an SSE stream:
-   - The SSE stream **SHOULD** eventually include one JSON-RPC _response_ per each
-     JSON-RPC _request_ sent in the POST body. These _responses_ **MAY** be
-     [batched](https://www.jsonrpc.org/specification#batch).
-   - The server **MAY** send JSON-RPC _requests_ and _notifications_ before sending a
+   - The SSE stream **SHOULD** eventually include JSON-RPC _response_ for the
+     JSON-RPC _request_ sent in the POST body.
+   - The server **MAY** send JSON-RPC _requests_ and _notifications_ before sending the
      JSON-RPC _response_. These messages **SHOULD** relate to the originating client
-     _request_. These _requests_ and _notifications_ **MAY** be
-     [batched](https://www.jsonrpc.org/specification#batch).
-   - The server **SHOULD NOT** close the SSE stream before sending a JSON-RPC _response_
-     per each received JSON-RPC _request_, unless the [session](#session-management)
+     _request_.
+   - The server **SHOULD NOT** close the SSE stream before sending the JSON-RPC _response_
+     for the received JSON-RPC _request_, unless the [session](#session-management)
      expires.
-   - After all JSON-RPC _responses_ have been sent, the server **SHOULD** close the SSE
+   - After the JSON-RPC _response_ has been sent, the server **SHOULD** close the SSE
      stream.
    - Disconnection **MAY** occur at any time (e.g., due to network conditions).
      Therefore:
@@ -133,9 +123,7 @@ MCP endpoint.
    this HTTP GET, or else return HTTP 405 Method Not Allowed, indicating that the server
    does not offer an SSE stream at this endpoint.
 4. If the server initiates an SSE stream:
-   - The server **MAY** send JSON-RPC _requests_ and _notifications_ on the stream. These
-     _requests_ and _notifications_ **MAY** be
-     [batched](https://www.jsonrpc.org/specification#batch).
+   - The server **MAY** send JSON-RPC _requests_ and _notifications_ on the stream.
    - These messages **SHOULD** be unrelated to any concurrently-running JSON-RPC
      _request_ from the client.
    - The server **MUST NOT** send a JSON-RPC _response_ on the stream **unless**

docs/specification/draft/basic/transports.mdx

@@ -7,7 +7,9 @@ the previous revision, [2025-03-26](/specification/2025-03-26).
 
 ## Major changes
 
-1. TODO
+1. Removed support for JSON-RPC **[batching](https://www.jsonrpc.org/specification#batch)**
+   (PR [#416](https://github.com/modelcontextprotocol/specification/pull/416)) 
+2. TODO
 
 ## Other schema changes