Free tool

REST API to MCP Server in PHP

What it actually takes to expose a REST API as an MCP server in PHP — the SDK, a working tool, and the part that decides whether an agent uses it correctly.

Community SDK community SDKs
Install
composer require ...
A working MCP tool in PHP
// Community SDK. Note this process stays alive across requests, unlike typical PHP.
$server = new McpServer('my-server');

$server->tool(
    'get_order',
    'Look up one order by its id and return its current status.',
    ['orderId' => ['type' => 'string', 'description' => 'The order id to look up']],
    fn(array $args) => fetch_order($args['orderId'])
);

$server->run();

It runs. Nobody else can see that.

A working server is where the effort ends and the selling starts. Point MCP Showcase at it and get a live playground your customers can try, with documentation generated for every tool.

How it works

link
Install the SDK

Shown above, along with whether it is officially maintained or a community project — which matters more in some languages than others.

play_circle
Wrap one endpoint

Start with a single tool, not your whole API. Tool definitions are sent to the model on every request, and selection accuracy falls as the list grows.

checklist
Test it before you connect an agent

Run the deployed URL through the MCP Inspector to confirm the handshake completes and the tools appear as you intended.

The PHP SDK

composer require ...community SDKs, a community project: there is no SDK under modelcontextprotocol for PHP.

That matters more than it sounds. The protocol has moved quickly, particularly around transports, and a port that stopped tracking spec revisions will work with some clients and silently fail with others. Check the last revision the library followed before you build on it.

Long-running processes are the awkward part

MCP servers hold a session; the usual PHP request-per-execution model does not. A PHP MCP server therefore runs as a long-lived process (or via a framework built for that), which is a bigger departure from normal PHP deployment than the protocol itself is.

Wrapping a REST endpoint

An MCP server is a thin layer over code you already have. Each tool needs three things: a name, a description saying what it does and when to choose it, and an input schema. The PHP SDK handles the protocol; what you write is the mapping from those arguments to your existing HTTP call.

Start with one endpoint rather than your whole API. Tool definitions are re-sent to the model on every single request, so each one is a permanent context cost, and the model's ability to pick correctly falls as the list grows. Eight well-described tools beat eighty.

The part that is not about PHP

Whatever language you use, the descriptions decide whether the agent behaves. They are read by the model, not by your colleagues, and a tool described in three words gets called by guesswork. You can check yours with the MCP schema linter, and see what the list costs per request with the token calculator.

Related tools and guides

A working server is half the job

Once it runs, the remaining problem is that nobody can tell what it does. A prospect cannot read your PHP source and will not install a client to find out. MCP Showcase points at the same URL and produces a live playground with generated documentation for every tool, so evaluating your server takes a click.

Frequently asked questions

Wrap each endpoint you want an agent to reach in a tool: a name, a one-sentence description of what it does and when to use it, and an input schema. The PHP SDK handles the protocol; what you write is the mapping from tool arguments to your existing HTTP call.

No, and this is the most common mistake. Tool definitions are re-sent on every single request, so eighty endpoints is eighty descriptions in the context window of every turn — and the model's ability to pick the right one drops sharply as the list grows. Start with the few an agent genuinely needs.

The badge above the code says which. Where there is no official SDK, community options vary in how closely they track the spec — check when the library last followed a protocol revision, particularly around transports, before you build on it.

Streamable HTTP for anything deployed. Clients increasingly try it first and some no longer fall back to the older HTTP+SSE transport, which shows up as a client that simply cannot see your server rather than as an error.

You cannot tell by reading your own code, because you already know what the tools do. Run the server through the schema linter: it checks the descriptions and input schemas the way a model reads them and flags the ones that would make an agent guess.

More free MCP tools