Add integration tests for a server with SSE transport

[Chrisbattarbee]

Integration tests should:

1. Spin up an MCP server
2. Query all the generated endpoints (list, initialize etc), validate that the response is as expected
3. Query the user specified endpoints for tools, resources etc, validate that the response is as expected
4. Make incorrect queries, validate that the server returns appropriate errors and recovers correctly

[svperfecta]

Would be nice to be able to instantiate multiple servers, and mount each on a base_path.

• FooServer -> /foo
• BarServer -> /bar

It will make having a single monolithic server make more sense, and (when auth is supported) make it easier to implement ACLs.

[svperfecta]

Would also be nice to add middleware support.

[Chrisbattarbee]

Definitely agree, the way I'm imagining that SSE should work is that the transport will register itself onto an existing http server as a handler.

My personal use case is that I want to use our existing http servers (gin) to also host MCP servers so we'll definitely support this.

I don't quite have a lot of the specifics fleshed out in my mind right now, I'll probably write up a proposal later this week after looking at some of the implementations in the official sdks.

[svperfecta]

We're thinking of cloud hosting ours, using gRPC with a custom auth middleware, and doing something like running a local (generated) grpc proxy. For now, we'll do something like store a JWT locally which is passed along for authentication / authorization to the proxy, which unlocks certain endpoints. (This is a short term hack until they figure out a real auth / auth model.)

[Chrisbattarbee]

Yeah makes sense, the current proposal PR for auth (support for JWT and oauth) is here modelcontextprotocol/modelcontextprotocol#101 if anyone happens to find this later

[Chrisbattarbee]

@svperfecta #59 Just added support for a stateless subset of MCP for gin servers, it doesnt support things like notifications and bidirectional communication but does work for common tool calling use cases. You can mount it on a single POST endpoint and access the gin request context through a propagated context. Allows you to have whatever middleware you like. Let me know if that's what you're looking for, we'll be basing our own MCP server exposed over the web on this.

[a67793581]

Do I need to help you implement it? Author @Chrisbattarbee @nikolubbe @ecekyn @GodlikePenguin

[a67793581]

@svperfecta #59 Just added support for a stateless subset of MCP for gin servers, it doesnt support things like notifications and bidirectional communication but does work for common tool calling use cases. You can mount it on a single POST endpoint and access the gin request context through a propagated context. Allows you to have whatever middleware you like. Let me know if that's what you're looking for, we'll be basing our own MCP server exposed over the web on this.

https://github.com/modelcontextprotocol/specification/blob/main/docs/specification/draft/basic/authorization.md

[svperfecta]

Awesome stuff guys!