[Client] (Re-)Implement Client component

[chr-hertel]

The MCP specification defines a client-side, and also the php-mcp had a component tackling that.

The goal of this issues is to bring in a first state of a Client as Mcp\Client.

---

Please announce yourself before working on this - so we can avoid duplicate effort.

[stof]

should this be part of the same package or should we have separate packages for the server side and client side SDKs ? Most projects will probably need only one side of the protocol.

[chr-hertel]

totally get the point - was @CodeWithKyrian and thinking as well, but i would also look at what other SDKs do here - with PHP we'd need some splitting tho for multiple packages per repo

[CodeWithKyrian]

Yeah, most of the other sdks in the organization combine both in same package so it makes sense to join the trend in this case.

It just means we have to make sure both the client and server are on the same spec version at all times

[jormeijer]

From my perspective, separation makes a lot of sense. In most cases you only need one of the two, and keeping them independent avoids unnecessary dependencies. A shared layer for common definitions (DTOs, contracts) could still add consistency without tying server and client together too tightly.

I’ve already have experience with building a PHP MCP client, so I’d be happy to share insights from that journey if it’s helpful. Not to push a specific implementation, but to give some inspiration when you start designing the client side of the SDK. swisnl/mcp-client

If there’s interest, I’d love to contribute or collaborate on shaping the client feature.

[chr-hertel]

Hi @jormeijer, it's not that we don't see the value - but also the harm would only persist with having unnecessary or conflicting dependencies by client vs server - if it's only a bunch of PHP files. Anyhow, the motivation is to keep it in one repo, and for now without split unless we solve a real issue.

Coming to your second point, yes, contributions on the client would be great - with @CodeWithKyrian's solution in php-mcp/client we also have a starting point, but someone needs to take over that action item :)

[butschster]

I’d actually argue in favor of splitting client and server into two separate repositories/packages.
The reasoning is mostly around release policy and developer clarity:

• Independent release cycles
  Very often, client and server evolve at different speeds. Having them in separate packages makes it crystal clear to users what exactly changed — if a new release is published for the client, it doesn’t imply anything changed for the server, and vice versa. This lowers confusion and gives consumers more confidence in upgrading.

• Simpler usage for developers
  Most projects will only ever need one side of the protocol. With separate packages, developers don’t pull in unnecessary dependencies or code they’ll never touch. This also makes it easier to understand the changelog and upgrade impact.

• Decoupled development teams
  Separate repos/packages allow two groups of contributors to move independently. Client and server concerns are often quite different, so this setup helps distribute ownership and reduces coordination overhead.

[chr-hertel]

Let's focus on the item of re-implementing the client here - other arguments have been acknowledged. The decision for now is just to have it in one package.

[ineersa]

I'm working on terminal coding assistant now in PHP (dumb idea, but why not), and it's at the point of complete TUI and working chat with LLM, next step is connecting actual tools. Now I'm rewriting few python tools I had to PHP and will move forward with MCP client. I guess i will try with https://github.com/php-mcp/client first to see how it works and what i actually need and could help out here with some minimal implementation after. It won't be soon tho, maybe in a few weeks.