DEV Community: exakat, static analysis for PHP

PHP Meets AI: The Official MCP SDK Adds Support for the Stateless 2026-07-28 Spec

exakat, static analysis for PHP — Tue, 15 Sep 2026 15:06:41 +0000

Web development and AI keep moving closer together, and PHP is part of that. On July 28, 2026, the Model Context Protocol (MCP) shipped its latest specification, 2026-07-28. The official PHP SDK, available at github.com/modelcontextprotocol/php-sdk, has been adding support for it. PHP developers can now build MCP servers and clients that work with both the new stateless protocol and earlier revisions.

What is MCP?

The Model Context Protocol is an open standard for connecting AI applications to external tools and data sources. An MCP server exposes capabilities such as tools, resources, and prompts. An MCP client, usually part of an AI application, discovers and uses them. This lets an AI assistant work with your files, databases, and APIs through one common interface instead of a custom integration for each.

MCP specifications are named by release date rather than version number. The 2026-07-28 release is the fifth spec release and one of the most significant so far.

What's New in the 2026-07-28 Specification?

The headline change is a stateless protocol core. MCP was previously a stateful, bidirectional protocol. Every connection began with an initialize handshake, and remote servers tracked sessions with an Mcp-Session-Id header. The new revision removes both, so every request is self-contained. Any server instance behind a load balancer can handle any request, without sticky routing or a shared session store.

Other notable changes include:

Multi Round-Trip Requests (MRTR): a way to gather input mid-call without holding a stream open.
Header-based routing: new Mcp-Method and Mcp-Name headers let gateways route and meter traffic without parsing request bodies.
Cacheable list results: list and read responses can carry freshness and cache-scope hints.
Authorization hardening: closer alignment with production OAuth 2.0 and OpenID Connect deployments.
An extensions framework: capabilities such as Tasks and MCP Apps can now evolve on their own timeline.
A formal deprecation policy: implementers get clearer guarantees about how long features will be supported.

This is a breaking change to the wire protocol, so SDKs need to support both the new revision and older peers during the transition.

PHP MCP for the world

PHP runs about 70% of websites whose server-side language is known (W3Techs), from custom business applications to WordPress, Drupal, and sites built on frameworks like Laravel and Symfony.

A stateless protocol also suits how PHP usually runs. In PHP's typical model, each request is handled independently and nothing is shared between requests. Under the older, session-based protocol, that model needed workarounds. Under 2026-07-28, it simply fits.

About the Official PHP SDK

The official SDK was announced in September 2025. It was built by the PHP Foundation, Anthropic's MCP team, and the Symfony team, and it consolidated earlier community work, including the PHP-MCP project, into one trusted implementation. The Symfony team leads maintenance, with Kyrian Obikwelu of PHP-MCP as a maintainer. The first release was server-only, and client support was added later.

The SDK includes:

A framework-agnostic API: it works in any PHP application. Integrations already exist for Symfony, Drupal, API Platform, CakePHP, Nette, and Kirby.
Server building blocks: you can expose your PHP code and data as tools, resources, resource templates, and prompts.
A client SDK: your PHP applications can connect to and talk to MCP servers.
Transports: STDIO for local servers and Streamable HTTP for remote ones.
Sessions and authorization: these cover the older, session-based protocol revisions as well as authorization support for HTTP servers.
Support for both protocol eras: the initialize-handshake revisions and the stateless 2026-07-28 revision.
Conformance tracking: the SDK is tested weekly against the official MCP Conformance Test Framework.

A Note on Maturity

The SDK is still pre-1.0. The latest release at the time of writing is v0.8.1, and the project describes itself as experimental until its first major release. Its 2026-07-28 conformance scores are measured against alpha versions of the test framework, so they will change as new test scenarios are published. Work on individual parts of the new spec is tracked openly in the repository's issues.

As with any library, review the defaults before you deploy to production. That includes HTTP settings such as CORS headers.

Get Started

Install the SDK with Composer:

composer require mcp/sdk

Documentation is available at php.sdk.modelcontextprotocol.io, and the code, examples, and roadmap are in the official repository:

👉 github.com/modelcontextprotocol/php-sdk
👉 Announcing the Official PHP SDK for MCP
👉 Get started with PHP MCP SDK

The SDK is still maturing, and the maintainers welcome feedback, bug reports, documentation fixes, and framework integrations. With the 2026-07-28 spec, the protocol now matches how PHP applications already run.

PHP

exakat, static analysis for PHP — Wed, 26 Mar 2025 17:42:50 +0000

Features that make PHP go forward

exakat, static analysis for PHP — Fri, 19 Jan 2024 21:14:20 +0000

Features that make PHP go forward

Open source projects often support older PHP versions, and sometimes, really much older. At some point, they take the decision to move on. With the drop of older versions, (relatively) new features can be used to modernize the sources. These features are the ones that make PHP go forward: they are wanted and awaited.

To detect which PHP features are important enough to trigger the abandonning of arcane PHP versions, we went a wide spanning audit and linted 51 modern PHP projects with PHP 8.0 and 7.4. Then, we checked what syntax error does the code yield with old PHP versions. By using these features, the backward incompatibility with now gone.

General compatibility with PHP 7.4 and 8.0

Out of the 51 projects, 18 projects generate no linting error with PHP 7.4; 20 projects generate no linting error with PHP 8.0. This gives 35% of PHP projects are still ensuring backward compabitibility with PHP 7.4; and a little less than 40% are ensuring PHP 8.0 backward compatibility.

The other projects are all displaying some incompatibility with these versions. It ranges from 1 file to 695 files, or up to 14% of the code base, incompatible with PHP 8.0.

Most frequent adopted features for PHP 8.0

Here are the most frequent features that are making the code backward incompatible. The percentage is the number of projects that are displaying a related error, divided by the number of projects that are backward incompatible. For example, an enumeration enum e {} yield syntax error, unexpected identifier "e" in PHP 8.0, and not in PHP 8.1.

The enumerations (PHP 8.1) are the feature that most often breaks backward incompability in modern code: it happens in 45% of the projets.

Then, readonly properties (PHP 8.1) while readonly classes are not yet visible. Intersectional types (A&B, PHP 8.1) and first class callable (strlen(...), PHP 8.1) are all close, with about 20% of compatibility breaks.

Last, but not least, are constant visibility and final classes. Final classes are not appearing.

Most frequent adopted features for PHP 7.4

When projects reach PHP 8.0, they start using the following features:

Promoted properties is a clear winner for adoption. It is a reason to drop backward compatibility in 2 cases out of 3.

Other omitted errors

There are a lot more incompatibilities between PHP middle versions (PHP 8.1, PHP 8.2, PHP 8.3...) than simply lint. Notably, the linting process stops at the first encountered error, and there may be a lot more errors later. Yet, this audit only counts the first one.

Also, some incompatibilities are only visible at execution time: they are left out of this analysis.

Choosing the features that make PHP go forward

It is interesting to discover which are the PHP features that are awaited, in projects that prevents themselves from using them to preserve PHP backward incompatibilities.

It is a reverse scenario, compared to the delivery of a new PHP version. When the project decides to move one, these new features are widely available, and usually well understood by coders. This prevents using features because they are new or fashionable. Only the real ones are adopted.