Repository navigation
Slicing the SDK into Multiple Packages #489
Description
Activity
- addedneeds confirmationNeeds confirmation that the PR is actually required or needed.Needs confirmation that the PR is actually required or needed.needs maintainer actionPotentially serious issue - needs proactive fix and maintainer attentionPotentially serious issue - needs proactive fix and maintainer attention
on Aug 29, 2026 @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-clientinstead ofphp-client, but I'm rather unemotional about that.Reacted by Antoine BluchetGood 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.Reacted by Christopher Hertel@chr-hertel I think
modelcontextprotocol/php-sdk-clientmakes sense to me to align with other formats that aretypescript-sdkorgo-sdk.If
php-sdksplits intophp-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-sdkthat bundles everything and serves as the single entry point.Reacted by Christopher Hertel
Package slicing
It was discussed already before and we should get this sorted before tagging v1.0: Slicing the monolithic
mcp/sdkpackage into multiple packages.At least the following packages make sense to me:
mcp/clientmcp/schemamcp/serverUnclear 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:
=> meaning PRs only hit
modelcontextprotocol/php-sdkand 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:
Maybe deptrac or similar to enforce.
This is a maintainer issue - community contributions won't be accepted but closed.