Can we move the transports to separate packages?

[paoloricciuti]

Is your feature request related to a problem? Please describe.
Right now the MCP server builder and the transport live in the same package. This is good because you don't have to install multiple dependencies but it's bad because it means that regardless of the transport you decide to use you are installing dependencies that are related to the default transport.

This is really not needed since what an MCP server really is is a jsonrpc server so the only concern should be to consume jsonrpc requests and return jsonrpc responses (as plain JS objects).

By doing this if I want to build a stdio i don't need to have express in my dependencies (same if I want to build it with a framework that uses a regular Request/Response.

Describe the solution you'd like
We should have an agnostic @modelcontextprotocol/sdk that only consume and produce JSONrpc and a @modelcontextprotocol/stremable-http @modelcontextprotocol/stdio packages that provide the transport.

Describe alternatives you've considered
Build my own JSONrpc handler that follows the MCP.

[43081j]

i think we should also move the server side of it to use something simpler than express

we don't need a full blown web server and could probably use polka or h3.

it'd trim a huge chunk of the dependency tree out, which would be a nice win

[paoloricciuti]

i think we should also move the server side of it to use something simpler than express

we don't need a full blown web server and could probably use polka or h3.

it'd trim a huge chunk of the dependency tree out, which would be a nice win

I'm actually building an alternative library that use native request and response so you can use it with whatever you want

https://github.com/paoloricciuti/tmcp

[KKonstantinov]

This will be handled in v2 of the SDK, please follow #809

Contributors will be welcome to help modernize the SDK in v2