Hosting MCP servers written in PHP

[roxblnfk]

Motivation

Writing an MCP server in PHP today means implementing the transport yourself, or holding a PHP process per SSE connection. Rapira can own the protocol plumbing, so PHP only implements tools, resources and prompts.

Rapira side (Rust)

• Streamable HTTP transport, JSON-RPC framing, SSE streams.
• Session management (Mcp-Session-Id) and resumability.
• Authorization (OAuth 2.1 per spec) at the server level.
• Protocol-level metrics: calls per tool, latency, errors, active sessions.

PHP side

Tool, resource and prompt calls arrive as ordinary worker invocations. Idle sessions and open SSE streams cost no workers.

Hard cases

• Long-running tools: progress notifications and cancellation propagated to the worker.
• Server-initiated requests (sampling, elicitation): the tool call must suspend until the client responds, using the same continuation mechanism proposed in the LLM gateway discussion.
• Session state: kept in Rapira (preferred) or in a worker, which requires affinity.

Open questions

1. Our own PHP API, or a transport for existing PHP MCP SDKs so they run on Rapira unchanged?
2. Where does session state live, and what is the storage API for PHP?
3. Core or plugin?
4. Should sampling route through the LLM gateway when the client doesn't support it?

[RyanAccuWebCloud]

Hello @roxblnfk

Yeah, I think this is going in the right direction. The "keep a PHP process around for every SSE connection" part is probably the biggest pain point here, especially on shared hosting or a regular PHP-FPM setup. So having Rapira take care of the transport makes a lot of sense.

A few thoughts on the questions you raised:

Own PHP API vs. transport for existing SDKs?

I'd definitely say transport for the existing SDKs.

There are already a few PHP MCP implementations out there (the official one, Logiscape's, and a couple of others), and I don't really see a reason to start another SDK from scratch unless there's a really good reason for it. If Rapira can expose something like a PSR-18 client and a session store interface, I think most of these could be adapted without too much trouble.

The only annoying part is that not every SDK separates the protocol stuff from the actual transport very cleanly. The official one does this reasonably well. Logiscape's is more stateless-per-request, which actually fits pretty nicely with what you're proposing, so that might be worth using as a reference.

Where does session state live?

I'd say Rapira, if that's practical.

If the workers keep the state, you need affinity, then sticky sessions, and you're basically back to dealing with the same problem in a different form.

If Rapira keeps the state, the PHP workers can stay stateless: request comes in, do the tool call, return the result. That's kind of the whole point of putting Rapira in the middle.

For the storage API, I'd keep it simple. A key/value interface with TTL should probably be enough for most use cases. If somebody needs Redis or something else underneath it, they can use that. I wouldn't make the storage layer more complicated than it needs to be.

Core or plugin?

I'd keep it in core.

Transport, session handling and auth are the things I wouldn't want every plugin to have to figure out for itself. Tools, resources and prompts make sense as the plugin layer.

Otherwise I can see transport becoming one of those things where there are five different implementations floating around and none of them quite work the same way.

Should sampling route through the LLM gateway?

One thing I'd flag here is that sampling is basically on its way out. It was deprecated in the 2026-07-28 revision and is supposed to be removed in 2027. On newer clients, sample() just throws.

So personally I'd focus on the multi-round-trip / elicitation approach instead. The SDKs already support that.

If an old client comes along expecting sampling, I'd treat that as a compatibility issue on the client side rather than something Rapira needs to build routing around. You could route it through the LLM gateway, sure, but it feels like a lot of infrastructure for something that's already being removed.

On the hard cases generally:

For long-running tools, progress and cancellation, the Tasks extension (SEP-2663) already handles a lot of this.

The basic idea is that the tool call gives you a task handle, then the client can poll or cancel it, while the state stays around between HTTP requests. That seems like something Rapira can mostly proxy rather than inventing its own mechanism.

The continuation thing you mentioned in the LLM gateway discussion also looks pretty close to InputRequiredResult / ClientGateway::elicit(). So there are already some patterns there that could be reused instead of designing the whole thing from scratch.

One thing I'd push back on:

I like the idea of framing this as "PHP only implements tools, resources and prompts", but I'd be a little careful with that.

Resources and prompts have their own lifecycle stuff, especially subscriptions and list-changed notifications. They're not quite the same thing as a tool call, so I wouldn't lump all of that together too much.

Overall though, yeah, I'd build it.

I'd target the stateless 2026-07-28 world rather than trying to make the old SSE-per-connection model work. That's where the protocol is heading anyway, and it fits PHP a lot better.

Regards,
Ryan | AccuWeb Cloud