Idea: Separate abstract and implementation SDKs

[JasonTheAdams]

Greetings! 👋

I'm part of the team developing the AI packages for WordPress, and work alongside @galatanovidiu on the MCP Adapter.

I was chatting with Ovi about the different integration challenges the SDK has for various projects such as WordPress, Drupal, Laravel, and so forth. I had an idea that I'd like to share here for friendly consideration. First, let me lay out my thought process:

MCP in PHP Structures
Arguably the most important part of this SDK for many of us is taking the complex and evolving MCP specification and representing it in PHP structures. Having things like a Server class that has an MCP Component registry, and DTOs for things like Tools, Prompts, and so forth, is such a big deal. Learning the specification in the first place and then translating that into PHP data structures is so valuable.

Implementation Challenges
The subsequent challenge is taking these data structures and making it actually do something. Hahah! Whether that's through CLI, HTTP, or whatever. WordPress, Laravel, Drupal, and such all have distinct systems for routing, handling HTTP transports, and so forth. Trying to make a system that adapts to each libraries special snowflake needs is a significant undertaking.

Separate packages?
So what if we separated these challenges? What if there were php-data-sdk and php-server-sdk structures? The later depending on the former. This would give folks like us, building the MCP Adapter, an immediately high value way of sharing the php-data-sdk and contributing back to it. It's also a nice separation of concerns as that package becomes strictly about making sure it accurately represents the latest MCP spec, and can even have its versioning match it.

Ideally the data structure would be PHP 7.4 compatible for those of us still working with hosts to push along PHP in the web, and then having the PHP 8.x be on the server level.

Anyway, there's my idea! I'm curious what others think! 😄

[chr-hertel]

Hi @JasonTheAdams, nice to meet you & great to get this going :)

that's a pretty valid and solid idea - even to that degree that we had it before IIRC. until now we always opted out since we focus on having everything in one repository without subtree split - makes it easier and i usually tend to think that a few extra classes around in vendor directory are not that harmful. but from a design point of view we already separate Mcp\Schema, Mcp\Server and Mcp\Client - but not yet as package - with different php reqs that might help tho.

raised that item again within discord to get some guidance how other SDKs handle that

Thanks for raising that again!

[JasonTheAdams]

Thanks, @chr-hertel! I appreciate the input and validation!

If it's important to keep it together, a case could pretty easily be made to turn this into a monorepo. Especially when bundling things in and a the scale of WordPress, we do like to be mindful of not including things we're not actually using. In this case, I'm open to continue exploring how we can take advantage of the Mcp\Server and Mcp\Client portions, but as I said it's simply much more complicated than including the schema.

It would be interesting to see what other SDKs do. A difference here is that many SDKs are about integrating with a specific system, whereas MCP is not a system but a specification. That's why, to me, the most important thing for the SDK to do is provide data structures which accurately reflect the MCP specification.

Thanks!