Slicing the SDK into Multiple Packages

[chr-hertel]

Package slicing

It was discussed already before and we should get this sorted before tagging v1.0: Slicing the monolithic mcp/sdk package into multiple packages.

At least the following packages make sense to me:

• mcp/client
• mcp/schema
• mcp/server

Unclear to me right now: how to deal with extensions? But that's not blocking.

Namespaces

In my understanding this comes with some major shifts in namespaces:
everything that is under Mcp\* needs to go into one of those:

• Mcp\Client\*
• Mcp\Schema\*
• Mcp\Server\*

Exceptions would get distributed into three namespaces below that - with one central interface each.

Monorepo + Subtree Splits

Development (incl. issues and PRs), docs, examples and releases would still happen via the main repository https://github.com/modelcontextprotocol/php-sdk, but the tree packages split into read-only subtrees:

• https://github.com/modelcontextprotocol/php-client
• https://github.com/modelcontextprotocol/php-schema
• https://github.com/modelcontextprotocol/php-server

=> meaning PRs only hit modelcontextprotocol/php-sdk and versioning across all packages is synced.

Cross Dependencies
Decoupling namespaces might be the annoying change here, but we should slice cleanly and enforce proper inter-dependencies:

• Client can use Schema, but not Server
• Server can use Schema, but not Client
• Schema mustn't use Client nor Server

Maybe deptrac or similar to enforce.

---

This is a maintainer issue - community contributions won't be accepted but closed.

[chr-hertel]

@felixweinberger do you have any guidance or requirements on the naming of the additional repositories?

Alternative that comes to my mind would be modelcontextprotocol/php-sdk-client instead of php-client, but I'm rather unemotional about that.

[soyuka]

Good idea especially the rules around dependencies between inter-components. At some point it'd be nice to also resolve issues around Schema generation and allow to plug other libraries in there.

Aren't extensions also tight to a specific component? Mcp\Client\Extension and Mcp\Server\Extension will probably exist at some point?

I guess with composer we have no other solution then to host a public readonly repo if we want to split components, I'd pick modelcontextprotocol/php-sdk-client.

[felixweinberger]

@chr-hertel I think modelcontextprotocol/php-sdk-client makes sense to me to align with other formats that are typescript-sdk or go-sdk.

If php-sdk splits into php-sdk-* that also makes it trivial to search and find :)

cc: @localden for thoughts in case there are any concerns about having additional repos, but I don't really see an issue here given we'll still have a php-sdk that bundles everything and serves as the single entry point.