Background

Today, mcp-use is published as a single package that exposes multiple entry points to avoid loading unnecessary dependencies and reduce conflicts.

• mcp-use/agent
• mcp-use/client
• mcp-use/browser
• mcp-use/react
• mcp-use/server

While this approach works, it adds complexity to the build setup, bundling strategy, and dependency management. Consumers may also install dependencies they never use.

Problem

• One package contains multiple environments
• Bundling logic is complex and fragile
• Dependency conflicts are harder to reason about
• Tree shaking and environment specific installs are not as clear as they could be

Proposal

Split mcp-use into multiple scoped packages, each targeting a specific runtime or responsibility.

Proposed packages:

• @mcp-use/agent : MCPAgent + deps
• @mcp-use/client : MCPClient with react, browser and node exports
• @mcp-use/server MCPServer with node and edge runtime support
• @mcp-use/core : common shared libs

Open Questions

• Migration cost for existing users
• Whether to keep a core package that re exports common functionality
• Naming and scope decisions for browser and react packages
• Versioning strategy across packages