php-sdk/docs/index.md
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

105 lines
3.5 KiB
Markdown

# 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](https://thephp.foundation/) and the
[Symfony project](https://symfony.com/). 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](https://symfony.com/doc/current/contributing/code/experimental.html)
until the first major release; see the
[roadmap](https://github.com/modelcontextprotocol/php-sdk/blob/main/ROADMAP.md)
for what is planned next.
## Requirements
PHP 8.1+.
## Installation
```bash
composer require mcp/sdk
```
See [Installation](get-started/installation.md) for the optional PSR packages an HTTP
server or client needs.
## Example
Create a file `server.php`:
```php-file title="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](get-started/first-server.md) walks through running it, and
[Try it with the Inspector](get-started/inspector.md) opens it in a UI you can click
around in.
## Where to go next
* **[Get started](get-started/index.md)** takes you from `composer require` to a server
a real MCP host can talk to.
* What a server exposes — tools, resources, prompts — is **[Servers](servers/index.md)**.
* Getting it in front of clients (STDIO, HTTP, your existing Symfony or Laravel app) is
**[Running your server](run/index.md)**.
* What is available *inside* the functions you register is
**[Inside your handler](handlers/index.md)**.
* Building the other side, an application that *uses* MCP servers, is
**[Clients](client/index.md)**.
* The two protocol eras, and what revision `2026-07-28` changed, are
**[Protocol versions](protocol-versions.md)**.
* What gets deprecated, for how long, and where the SDK stands on spec-tier
support are under **Project**: **[Deprecation policy](deprecation-policy.md)**
and **[SDK tier target](sdk-tier.md)**.
* Complete, runnable projects are in **[Examples](examples.md)**.
* Hunting for an exact signature? The **[API Reference](https://php.sdk.modelcontextprotocol.io/api/)**
is generated from the source.