Session management in SSE transport

[zaira-bibi]

Background
We're integrating a third-party API with our MCP server, which requires credentials (like api key/token) for authentication. We need to support multiple instances in a single MCP server, which would require session management. My MCP server runs in SSE mode.

Current Implementation
We're providing the credentials as parameters to each tool, something like:

#[tool]
pub async fn my_tool(
    &self,
    Parameters(AuthParams { api_token }): Parameters<AuthParams>,
) -> Result<CallToolResult, ErrorData> 
    let client = MyClient::new(api_token);

    match client.request(Method::GET, "endpoint").await {
       // Rest of the implementation ...
    }
}

Problem
The current implementation is not a great design as passing credentials to each tool is redundant.

In order to add abstraction and to support other third-party APIs as plugins, we cannot define the API clients in the server itself. But we are lost on how to store the user credentials for each session.

We tried adding the Auth Params in the extension of RequestContext:

#[tool]
pub async fn save_credentials(
    &self,
    Parameters(AuthParams { api_token }): Parameters<AuthParams>,
    mut ctx: RequestContext<RoleServer>
) -> Result<CallToolResult, ErrorData> {
    ctx.extensions.insert(AuthParams {
        api_token
    });

    Ok(CallToolResult::success(vec![Content::text(
            "Credentials saved successfuly!",
     )]))
}

But the extensions remain empty in other tools.

Question
Is there a standard way we can achieve this? Any help would be appreciated. TIA!

[4t145]

Sorry I don't get it. Of course you cannot get the extension from another request. If you want to know the http query, headers or something else, you can get the http::Parts from extension, it will contain a session id in the query. And if you are working on a complex application, I strongly recommand you rewrite the sse_server part based on current version. You may need to manage sessions in distributed server, interact with db and cache... But you can see the current implementation just manage the sessions with an inmemory hashmap, apparently it is too simple to do it.

[4t145]

And implement a common use sse server could be a big challenge, we already have some discussion on it. Maybe we could make the current axum version more generic, just like the streamable http implementation. But we didn't have enough motivation to do it since offitial standard had abandoned sse transport.

[zaira-bibi]

Thanks so much for the reply!

rewrite the sse_server part based on current version

Could you please elaborate what you mean by this?

[zaira-bibi]

Moreover, is there a way we can pass additional context to the tools, like in Python's FastMCP tools we can have context managed by asynccontextmanager?

[4t145]

Could you please elaborate what you mean by this?

Our current SSE server is only a reference. If you need more complex functionality, you'll probably have to implement it yourself. Of course, it would be even better if you could implement a more powerful, general-purpose version.

Moreover, is there a way we can pass additional context to the tools, like in Python's FastMCP tools we can have context managed by asynccontextmanager?

You can inject extension by using http middleware, and it will be carried with http::request::Parts. And finally you can get it from RequestContext. Here's a similar issue #153. We don't have a good document about this now, I will try to write some about it. As for those "more global contexts", or saying "states", you can keep them through your Server structure itself.

But I am not a deep python user, so if there are any omissions in the function, you are welcome to report them.