index.md

Running your server

Server::builder() configures a server; run() puts it on a transport and starts answering. StdioTransport, StreamableHttpTransport and InMemoryTransport implement TransportInterface and are used the same way:

use Mcp\Server\Server;

$server = Server::builder()
    ->setServerInfo('My Server', '1.0.0')
    ->setDiscovery(__DIR__, ['.'], excludeDirs: ['vendor'])
    ->build();

$transport = new SomeTransport();

$result = $server->run($transport); // Blocks for STDIO, returns a response for HTTP

InMemoryTransport takes a list of JSON-RPC messages, handles them in order and discards the answers. Use it in tests.

StatelessHttpTransport works differently. It serves only protocol revision 2026-07-28. You create it with the result of buildStateless() and call handle() with the request. See Serving one era only.

Choosing a transport

The choice depends on the client you want to integrate with:

• The client runs locally and launches your server as a subprocess (Claude Desktop, most editors) → STDIO.
• The client is remote, or your server lives in a web application → HTTP, the Streamable HTTP transport.

The rest of this section:

• Server builder — every configuration knob: server info, discovery, dependency injection, logging, pagination.
• Framework integration — mounting the HTTP transport in a Symfony, Laravel, or Slim application, or running it standalone.
• Web servers — serving the endpoint with Nginx or Apache and PHP-FPM.
• Sessions — off over HTTP until you call setSession(); what needs them, and where per-client state lives once you serve HTTP from more than one process.
• Serving both eras — the same endpoint also answers protocol revision 2026-07-28, which has no handshake and no sessions; what a modern request carries, and how each one is routed.
• Caching — the ttlMs / cacheScope hints a modern-era result carries.
• Subscriptions — subscriptions/listen and the notification bus behind it.
• Authorization — validating OAuth 2 access tokens in front of the HTTP transport.