Provide a more flexible transport

[xtuc]

The client / server architecture, as described by https://modelcontextprotocol.io/docs/concepts/architecture#overview, doesn't fit the serverless use-case (talking for Cloudflare's Workers AI), in which: either the client is running on a server or both client/server are running on the server.

Would it be possible to add a new transport layer that's essentially a JS API, not involving any IO?

Moreover, MCP server are hardcoding a transport: https://github.com/modelcontextprotocol/servers/blob/df0b733c7d086432de14504863c9c0288fc36686/src/gitlab/index.ts#L526-L527, which makes them not easily portable.

[jspahrsummers]

I think this issue is describing three different things:

1. Agreed that the nature of the protocol is currently a poor fit for serverless deployments. I started Statelessness #102 to discuss this in more detail.
2. Transports are very easily written, so yes, it's possible to create a transport that runs whatever code you want instead of doing I/O.
3. It's a good point that perhaps servers don't need to hardcode transports! Would welcome any thoughts on how to generalize this without dictating too much of how the server itself is implemented.