Watch

Christopher Hertel 1e9520e731

[Docs] Deprecation policy, SDK tier target, and CONTRIBUTING.md (#472 )

* [Docs] Add deprecation policy doc (SEP-2596)

Formalizes the Active -> Deprecated -> Removed lifecycle and the
twelve-month deprecation window the SDK already applies via SEP-2577,
and states the SDK's own BC promise ahead of 1.0.

* [Docs] Add SDK Tier 2 gap analysis (SEP-1730)

* [Docs] Wire deprecation policy and SDK tier docs into the guide nav

Adds both pages under a new Project section in mkdocs.yml, links them
from index.md's "Where to go next", and points their repo-root
references at GitHub URLs instead of paths escaping docs/ (dead under
Zensical's --strict build).

* [Docs] Add CONTRIBUTING.md

Root-level contribution guide: dev setup, the make ci checks to run
before a PR, coding standards, testing expectations, the docs-guide
link-resolution rule Zensical enforces, and licensing terms. Linked
from README's existing Contributing section.

* [Docs] Trim deprecation policy per review

Drop the worked SEP-2577 example and the "relationship to the
protocol lifecycle" section; both were redundant restating of detail
that lives in the code/CHANGELOG and protocol-versions.md already.

* [Docs] Cite the Tier 3 audit and add a versioning policy (SEP-1730)

Replace our own hand-rolled conformance numbers with the authoritative
audit in modelcontextprotocol/modelcontextprotocol#3274: SDK is
currently Tier 3, blocked from Tier 2 by client OAuth conformance
(20%) and no stable 1.0.0+ release. Add the Versioning section the
audit found missing — SemVer commitment pre-1.0, Symfony's BC promise
after — and point CONTRIBUTING.md at it.

* [Docs] Link Symfony's BC promise from the deprecation policy

Was plain text; sdk-tier.md's Versioning section already links it.

* [Docs] Drop the "process gaps addressed" aside from sdk-tier.md

* Apply suggestion from @chr-hertel

* Apply suggestion from @chr-hertel

2026-08-24 01:23:52 +02:00

3.5 KiB

Raw Blame History

MCP PHP SDK

The Model Context Protocol (MCP) lets applications provide context to LLMs in a standardized way, separating the concern of providing context from the LLM interaction itself.

This is the official PHP SDK for it, a collaboration between the PHP Foundation and the Symfony project. With it you can:

Build MCP servers that expose tools, resources, and prompts to any MCP host.
Build MCP clients that connect to any MCP server.
Speak both standard transports: STDIO and Streamable HTTP.

!!! warning "Experimental until 1.0" This SDK is experimental until the first major release; see the roadmap for what is planned next.

Requirements

PHP 8.1+.

Installation

composer require mcp/sdk

See Installation for the optional PSR packages an HTTP server or client needs.

Example

Create a file server.php:

<?php

require __DIR__.'/vendor/autoload.php';

use Mcp\Capability\Attribute\McpResource;
use Mcp\Capability\Attribute\McpTool;
use Mcp\Server;
use Mcp\Server\Transport\StdioTransport;

class Calculator
{
    /**
     * Adds two numbers.
     */
    #[McpTool]
    public function add(int $a, int $b): int
    {
        return $a + $b;
    }

    #[McpResource(uri: 'config://calculator/settings')]
    public function settings(): array
    {
        return ['precision' => 2];
    }
}

Server::builder()
    ->setServerInfo('Calculator', '1.0.0')
    ->setDiscovery(__DIR__, ['.'], excludeDirs: ['vendor'])
    ->build()
    ->run(new StdioTransport());

That's a complete MCP server. It exposes one tool, add, and one resource, config://calculator/settings.

Attribute discovery needs symfony/finder (composer require symfony/finder). Without it the server still starts, but discovers nothing and only logs a warning.

Look at what you did not write: no JSON Schema — int $a, int $b is the schema — no request parsing, no serialization, no protocol handling. You wrote a PHP class with type hints and a docblock; the SDK does the rest.

First server walks through running it, and Try it with the Inspector opens it in a UI you can click around in.

Where to go next

Get started takes you from composer require to a server a real MCP host can talk to.
What a server exposes — tools, resources, prompts — is Servers.
Getting it in front of clients (STDIO, HTTP, your existing Symfony or Laravel app) is Running your server.
What is available inside the functions you register is Inside your handler.
Building the other side, an application that uses MCP servers, is Clients.
The two protocol eras, and what revision 2026-07-28 changed, are Protocol versions.
What gets deprecated, for how long, and where the SDK stands on spec-tier support are under Project: Deprecation policy and SDK tier target.
Complete, runnable projects are in Examples.
Hunting for an exact signature? The API Reference is generated from the source.

3.5 KiB Raw Blame History