Skip to content

Slicing the SDK into Multiple Packages #489

Description

@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:

=> 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.

Activity

  1. added this to the 1.0 milestone on Aug 29, 2026
  2. self-assigned this
    on Aug 29, 2026
  3. added
    needs confirmationNeeds confirmation that the PR is actually required or needed.
    needs maintainer actionPotentially serious issue - needs proactive fix and maintainer attention
    on Aug 29, 2026
  4. chr-hertel commented on Aug 29, 2026

    @chr-hertel
    MemberAuthor

    @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.

  5. soyuka commented on Sep 3, 2026

    @soyuka
    Contributor

    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.

  6. felixweinberger commented on Sep 15, 2026

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

needs confirmationNeeds confirmation that the PR is actually required or needed.needs maintainer actionPotentially serious issue - needs proactive fix and maintainer attention

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions