* [Docs] Render guides with Zensical, deploy via GitHub Pages actions phpDocumentor's guide renderer copies the markdown through mostly verbatim: relative links between pages keep pointing at `*.md` targets that do not exist in the built site, and nothing validates them, so the published guides are full of dead links. Zensical (the Material for MkDocs team's successor to MkDocs) resolves internal links against the page tree and fails the build on a broken one. `zensical build --strict` already found four dead links on the first run — three repo-relative links escaping docs/ (fixed to point at GitHub) and one wrong in-page anchor. phpDocumentor stays on for the class-level API reference only; `make docs` builds the guides into site/ and mounts the reference at site/api/, so its two header links back to the guides now target the site root. Deployment moves from pushing a gh-pages branch to the official GitHub Pages actions, and from release-only to every push on main, with pull requests building (but not deploying) so a broken link fails review instead of the site. NOTE: this needs the repository's Pages source switched to "GitHub Actions" (Settings -> Pages) once. * [Docs] Adopt the Python SDK's documentation look and feel The docs site now uses the same theme configuration as https://py.sdk.modelcontextprotocol.io/ so the language SDKs read as one set of docs: the MCP mark as logo and favicon, Inter/JetBrains Mono, the black/slate palette with a three-way (system/light/dark) toggle, instant navigation, code copy/annotate, and a right-hand table of contents. The markdown extension set is widened to the same list (tabbed blocks, task lists, footnotes, emoji/icons, mermaid fences), which the content restructure builds on. Styling is otherwise stock: no custom stylesheet, and Zensical's own `modern` theme variant, pinned explicitly rather than left to the default. The one departure is code highlighting, which is broken out of the box here: Pygments only highlights PHP after a `<?php` tag, so the guides — whose code blocks are almost all fragments — rendered as flat plain text. The `php` lexer is extended with `startinline`, and complete-file blocks use a `php-file` lexer that keeps the literal open tag highlighted. * [Docs] Restructure the guides into task-oriented sections The guides were ten flat pages, each opening with a hand-maintained table of contents and each mixing several audiences: `mcp-elements.md` covered tools, prompts, schema generation and handler-side logging, `transports.md` covered both transports plus framework integration, and `server-builder.md` covered configuration, sessions and custom message handlers. They are now split along the same lines as the Python SDK's documentation (https://py.sdk.modelcontextprotocol.io/), one topic per page: Get started installation, first server, the Inspector Servers tools, resources, resource templates, prompts, completions, schema generation, registration Inside your handler the ClientGateway, logging Running your server builder, STDIO, HTTP, framework integration, sessions, authorization Clients connecting, transports, capabilities, server-initiated requests, error handling Advanced events, protocol extensions, custom message handlers Prose is carried over as-is apart from the seams; what is new is the landing page and one index page per section, which say what the section is for and where to go next, so no page is a dead end. The per-page "Table of Contents" lists are gone — the theme renders one from the headings — and GitHub's `> [!IMPORTANT]` blockquotes became admonitions, which Zensical renders as callouts rather than plain quotes. Every code sample and factual claim was then checked against src/ and the runnable examples, which turned up long-standing errors in the carried-over prose. Samples that could not run: a prompt using a `system` role (MCP has only user/assistant), `Mcp\Schema\PromptMessage` (it is under `Schema\Content`) constructed with an array instead of a single content object, `Mcp\Capability\Prompt\Completion\ProviderInterface` (it is `Mcp\Capability\Completion\ProviderInterface`), `new EmbeddedResource(type:, resource: [...])` (neither parameter exists), a `: resource` return type (not a PHP type), `#[McpResource]` with a `{path}` variable (that is a template), a stray quote in the builder example, a `middlewares:` argument (it is `middleware:`), and `getRequest()->getAttribute()` in the OAuth guide (no such method — the values arrive on the request meta). Claims corrected: sampling's `system_prompt` option (it is `systemPrompt`), `SampleMessage` (it is `SamplingMessage`), `Notification` called an interface (abstract class), "parameter order matters" for URI templates (bound by name), full RFC 6570 support (only simple `{var}`), the tool description fallback chain, `void` returning empty content, a non-zero STDIO exit code, `ErrorEvent` being null for parse errors, handlers being "prepended", `Psr16StoreSession`, and PSR-3 log context being sent to the client (it is dropped). Sixteen `examples/` paths were missing their `server/` segment. README, the OAuth ADR and one source comment now point at the published site instead of at markdown files that moved. * [Docs] Run the docs workflow unfiltered, keep README links relative The `paths:` filters were mostly noise: `src/**` had to be in the list for the phpDocumentor build, which meant the workflow ran on nearly every PR anyway. They also missed two real inputs — `.phpdoc/template/**` and `composer.lock` — so a template tweak or a phpDocumentor bump could change the rendered site without triggering a build. README links go back to relative repo paths. The README is not part of the Zensical site (`docs_dir` is `docs/`), so those links are only ever resolved by GitHub and Packagist, where absolute URLs break in-repo navigation for no gain. The site pointer and the generated API reference stay absolute. * [Docs] Adopt the doc changes that landed on main into the new structure Twelve commits landed while the restructure was open, seven of them touching the flat guides this branch replaces. Renames merged on their own; the three files that were split apart needed their new sections placed by hand: - Connection retries, protocol version negotiation, sampling with tools and roots from `client.md` into `client/connecting.md` and `client/server-requests.md` - `ResourceLink` and structured output from `mcp-elements.md` into `servers/tools.md` - Protocol version negotiation from `server-builder.md` into `run/server-builder.md` The `setMaxRetries()` note claiming the value is never acted on is gone — #413 implemented it. Callouts became admonitions and cross-links were repointed at the new paths, as everywhere else in this branch. * [Docs] Document the elicitation and roots client examples Both were missing from the examples guide: the elicitation client predates this branch, the roots client arrived with #395. * [Docs] Fold the 2026-07-28 lifecycle into the new structure Main's stateless-lifecycle.md becomes a docs/lifecycle/ section, and the pages main touched — deprecations, the middleware split, the client's modern era — land where the restructure moved them. * [Docs] Link the Inspector to its documentation, not its repo * [Docs] Distribute the 2026-07-28 material into the task sections The Python and TypeScript SDKs file each feature where the task lives and keep only an era comparison on its own page. Follow them: input-required moves next to the other handler concerns, caching, subscriptions and era routing to "Running your server", and one Protocol versions page carries the rest. * [Docs] Move protocol version negotiation onto the Protocol versions page The builder page keeps the setProtocolVersion() knob and links out; how a revision is agreed now sits beside the era it belongs to. * [Docs] Slim the README to a funnel, turn Examples into an index * [Docs] Fix the code samples and API listings flagged by the audit * [Docs] Link the negotiation spec section at latest, not draft
260 lines
11 KiB
Markdown
260 lines
11 KiB
Markdown
# HTTP Transport
|
|
|
|
The HTTP transport was designed to sit between any PHP project, regardless of the HTTP implementation or how they receive
|
|
and process requests and send responses. It provides a flexible architecture that can integrate with any PSR-7 compatible application.
|
|
|
|
```php
|
|
use Psr\Http\Message\ServerRequestInterface;
|
|
|
|
// PSR-17 factories are automatically discovered
|
|
$transport = new StreamableHttpTransport(
|
|
request: $serverRequest, // PSR-7 server request
|
|
responseFactory: null, // Optional: PSR-17 response factory (auto-discovered if null)
|
|
streamFactory: null, // Optional: PSR-17 stream factory (auto-discovered if null)
|
|
logger: $logger // Optional PSR-3 logger
|
|
);
|
|
```
|
|
|
|
## Parameters
|
|
|
|
- **`request`** (required): `ServerRequestInterface` - The incoming PSR-7 HTTP request
|
|
- **`responseFactory`** (optional): `ResponseFactoryInterface` - PSR-17 factory for creating HTTP responses. Auto-discovered if not provided.
|
|
- **`streamFactory`** (optional): `StreamFactoryInterface` - PSR-17 factory for creating response body streams. Auto-discovered if not provided.
|
|
- **`logger`** (optional): `LoggerInterface` - PSR-3 logger for debugging. Defaults to `NullLogger`.
|
|
- **`middleware`** (optional): `iterable<MiddlewareInterface>|null` - PSR-15 middleware chain. `null` (omitted) installs the [default stack](#default-middleware). `[]` disables all defaults — useful when the surrounding application already handles CORS, host validation, etc.
|
|
- **`maxBodyBytes`** (optional): `int` - Upper bound on the POST request body read, in bytes. Defaults to 4 MiB (`StreamableHttpTransport::DEFAULT_MAX_BODY_BYTES`). See [Request Body Size Limit](#request-body-size-limit).
|
|
|
|
## PSR-17 Auto-Discovery
|
|
|
|
The transport automatically discovers PSR-17 factory implementations from these popular packages:
|
|
|
|
- `nyholm/psr7`
|
|
- `guzzlehttp/psr7`
|
|
- `slim/psr7`
|
|
- `laminas/laminas-diactoros`
|
|
- And other PSR-17 compatible implementations
|
|
|
|
```bash
|
|
# Install any PSR-17 package - discovery works automatically
|
|
composer require nyholm/psr7
|
|
```
|
|
|
|
If auto-discovery fails or you want to use a specific implementation, you can pass factories explicitly:
|
|
|
|
```php
|
|
use Nyholm\Psr7\Factory\Psr17Factory;
|
|
|
|
$psr17Factory = new Psr17Factory();
|
|
$transport = new StreamableHttpTransport($request, $psr17Factory, $psr17Factory);
|
|
```
|
|
|
|
## Default Middleware
|
|
|
|
When the `middleware` argument is omitted (or set to `null`), the transport installs a secure default stack:
|
|
|
|
| Order | Middleware | Purpose |
|
|
|-------|------------|---------|
|
|
| 1 | `CorsMiddleware` | Applies CORS headers to every response. By default does **not** set `Access-Control-Allow-Origin` (cross-origin requests are blocked). |
|
|
| 2 | `DnsRebindingProtectionMiddleware` | Validates `Origin`/`Host` against an allowlist. Defaults to localhost variants only. |
|
|
|
|
```php
|
|
// Zero-config, secure-by-default — local servers get full protection automatically.
|
|
$transport = new StreamableHttpTransport($request);
|
|
```
|
|
|
|
The default stack can be inspected and recomposed via the public factory:
|
|
|
|
```php
|
|
$middleware = StreamableHttpTransport::defaultMiddleware();
|
|
```
|
|
|
|
These run at the edge, before the request's protocol era is known, because what they enforce is true of
|
|
both eras. `ProtocolVersionMiddleware` is not in that stack: the `MCP-Protocol-Version` header rule belongs
|
|
to the handshake era, so the transport applies it only to requests it classified as handshake-era traffic,
|
|
and the modern leg answers for its own revisions. It is available as
|
|
`StreamableHttpTransport::handshakeMiddleware()` and is applied whether or not you replace the edge stack.
|
|
See [Serving both eras](protocol-eras.md).
|
|
|
|
## CORS Configuration
|
|
|
|
CORS is handled by `CorsMiddleware`. To enable cross-origin browser requests, configure it explicitly and pass it
|
|
in place of (or alongside) the defaults:
|
|
|
|
```php
|
|
use Mcp\Server\Transport\Http\Middleware\CorsMiddleware;
|
|
use Mcp\Server\Transport\Http\Middleware\DnsRebindingProtectionMiddleware;
|
|
use Mcp\Server\Transport\StreamableHttpTransport;
|
|
|
|
// Reflect a specific origin
|
|
$transport = new StreamableHttpTransport(
|
|
$request,
|
|
middleware: [
|
|
new CorsMiddleware(allowedOrigins: ['https://myapp.com']),
|
|
new DnsRebindingProtectionMiddleware(),
|
|
],
|
|
);
|
|
|
|
// Allow all origins (development only)
|
|
$transport = new StreamableHttpTransport(
|
|
$request,
|
|
middleware: [
|
|
new CorsMiddleware(allowedOrigins: ['*']),
|
|
new DnsRebindingProtectionMiddleware(),
|
|
],
|
|
);
|
|
```
|
|
|
|
When the allowlist is a concrete set of origins (not `['*']`), `CorsMiddleware` automatically adds `Vary: Origin`
|
|
so shared caches/CDNs do not serve a response generated for one origin to a request from another.
|
|
|
|
Headers already present on a response (e.g. set by inner middleware) are preserved — `CorsMiddleware` only adds
|
|
defaults when they are absent.
|
|
|
|
!!! warning
|
|
`Access-Control-Allow-Origin: *` is incompatible with credentialed browser requests (those carrying
|
|
`Authorization`, cookies, or client certificates). If your MCP server runs OAuth/Bearer auth and serves
|
|
a browser client, configure `allowedOrigins` with the explicit origin(s) you trust rather than `['*']`.
|
|
The middleware reflects the matching origin verbatim, which is the form browsers accept with credentials.
|
|
|
|
## DNS Rebinding Protection
|
|
|
|
`DnsRebindingProtectionMiddleware` validates the `Origin` header against an allowlist (falling back to `Host`
|
|
when `Origin` is absent). The default allowlist is localhost-only:
|
|
|
|
```php
|
|
use Mcp\Server\Transport\Http\Middleware\DnsRebindingProtectionMiddleware;
|
|
|
|
new DnsRebindingProtectionMiddleware(allowedHosts: ['myapp.local', 'mcp.internal']);
|
|
```
|
|
|
|
If the server is fronted by a reverse proxy that already validates `Host`, drop this middleware from the chain
|
|
or supply a permissive allowlist.
|
|
|
|
## Protocol Version Validation
|
|
|
|
`ProtocolVersionMiddleware` rejects requests whose `MCP-Protocol-Version` header is not in the SDK's supported
|
|
set with `400 Bad Request`. Requests without the header pass through, since the `initialize` round-trip and some
|
|
legacy clients do not send it.
|
|
|
|
It is applied by the transport itself, to handshake-era traffic only — do not add it to a custom `middleware`
|
|
list, where it would run before the era is classified and reject every modern-era request. Construct it
|
|
yourself only to narrow the supported set on a server that also pins its handshake:
|
|
|
|
```php
|
|
use Mcp\Schema\Enum\ProtocolVersion;
|
|
use Mcp\Server\Transport\Http\Middleware\ProtocolVersionMiddleware;
|
|
|
|
// Only accept the latest spec version
|
|
new ProtocolVersionMiddleware(supportedVersions: [ProtocolVersion::V2025_11_25]);
|
|
```
|
|
|
|
The default set is `ProtocolVersion::handshakeVersions()` — every revision the server can actually negotiate over
|
|
`initialize`, rather than every revision the enum declares. A request without the header is treated as
|
|
`ProtocolVersion::DEFAULT_HEADER_VERSION` (`2025-03-26`), the revision that introduced both Streamable HTTP and the
|
|
header itself, so a header-less request cannot be newer than that.
|
|
|
|
This header check is separate from, and happens after, the handshake itself. See
|
|
[Protocol versions](../protocol-versions.md#negotiating-in-the-handshake-era) for how the revision is agreed in the
|
|
first place. Being separate also means it is unaffected by `setProtocolVersion()`: the middleware validates against
|
|
the set it was constructed with, not against the revision a given session negotiated, so a server that pins the
|
|
handshake has to pass that revision here as well.
|
|
|
|
Modern revisions never reach it. A `2026-07-28` request declares its revision in `params._meta` rather than in a
|
|
header, and is routed away from this check entirely — see
|
|
[Serving both eras](protocol-eras.md).
|
|
|
|
## Request Body Size Limit
|
|
|
|
`StreamableHttpTransport` caps the POST body it reads to guard against memory exhaustion from an oversized or
|
|
unbounded (chunked) payload. The default cap is 4 MiB. A body over the cap is rejected with `413` and never reaches
|
|
message parsing.
|
|
|
|
```php
|
|
use Mcp\Server\Transport\StreamableHttpTransport;
|
|
|
|
// Raise the cap to 16 MiB
|
|
$transport = new StreamableHttpTransport($request, maxBodyBytes: 16 * 1024 * 1024);
|
|
```
|
|
|
|
When the request stream advertises a size, the transport rejects it up-front. Otherwise (e.g. chunked transfer with
|
|
unknown size) the body is read incrementally and aborted as soon as it crosses the cap, so an unbounded stream cannot
|
|
exhaust memory. A value below `1` throws `InvalidArgumentException`.
|
|
|
|
## JSON-RPC Batch Size Limit
|
|
|
|
A JSON-RPC batch (top-level array) is capped at 100 messages. Oversized batches are rejected before any
|
|
message is constructed, so a single small request cannot amplify into arbitrarily many operations. The cap
|
|
lives on `Mcp\JsonRpc\MessageFactory` and is not currently configurable through the builder — a server built
|
|
with `Server::builder()` always uses the default of 100.
|
|
|
|
Single-message vs batch is determined from the decoded JSON type — a JSON object is a single message, a JSON array
|
|
is a batch. Scalars, empty payloads, and non-object batch elements are returned as `InvalidInputMessageException`
|
|
entries (the existing per-message error contract), not parse errors or crashes. A `maxBatchSize` below `1` throws
|
|
`InvalidArgumentException`.
|
|
|
|
## Custom PSR-15 Middleware
|
|
|
|
`StreamableHttpTransport` accepts any PSR-15 middleware chain. To extend the defaults, spread them and append
|
|
your own middleware — the defaults stay outermost so CORS headers are applied to every response, including
|
|
short-circuited ones:
|
|
|
|
```php
|
|
use Mcp\Server\Transport\StreamableHttpTransport;
|
|
use Psr\Http\Message\ResponseFactoryInterface;
|
|
use Psr\Http\Message\ResponseInterface;
|
|
use Psr\Http\Message\ServerRequestInterface;
|
|
use Psr\Http\Server\MiddlewareInterface;
|
|
use Psr\Http\Server\RequestHandlerInterface;
|
|
|
|
final class AuthMiddleware implements MiddlewareInterface
|
|
{
|
|
public function __construct(private ResponseFactoryInterface $responses)
|
|
{
|
|
}
|
|
|
|
public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
|
|
{
|
|
if (!$request->hasHeader('Authorization')) {
|
|
return $this->responses->createResponse(401);
|
|
}
|
|
|
|
return $handler->handle($request);
|
|
}
|
|
}
|
|
|
|
$transport = new StreamableHttpTransport(
|
|
$request,
|
|
logger: $logger,
|
|
middleware: [
|
|
...StreamableHttpTransport::defaultMiddleware(),
|
|
new AuthMiddleware($responseFactory),
|
|
],
|
|
);
|
|
```
|
|
|
|
To selectively drop one default (for example DNS rebinding when running behind a proxy), filter the default list:
|
|
|
|
```php
|
|
use Mcp\Server\Transport\Http\Middleware\DnsRebindingProtectionMiddleware;
|
|
use Mcp\Server\Transport\StreamableHttpTransport;
|
|
|
|
$transport = new StreamableHttpTransport(
|
|
$request,
|
|
middleware: [
|
|
...array_filter(
|
|
StreamableHttpTransport::defaultMiddleware(),
|
|
fn ($m) => !$m instanceof DnsRebindingProtectionMiddleware,
|
|
),
|
|
new AuthMiddleware($responseFactory),
|
|
],
|
|
);
|
|
```
|
|
|
|
Pass `middleware: []` to disable every default and run only your own chain:
|
|
|
|
```php
|
|
$transport = new StreamableHttpTransport(
|
|
$request,
|
|
middleware: [new AuthMiddleware($responseFactory)],
|
|
);
|
|
```
|