modelcontextprotocol / modelcontextprotocol/kotlin-sdk
Access the ServerSSESession from inside a request (e.g. CallToolRequest, ClientRequest, etc)
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 1.5k
- Forks
- 248
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 23
Description
Is your feature request related to a problem? Please describe.
I followed the example:
fun runSseMcpServerUsingKtorPlugin(port: Int, wait: Boolean = true): EmbeddedServer<*, *> {
printBanner(port)
val server = embeddedServer(CIO, host = "127.0.0.1", port = port) {
installCors()
mcp {
return@mcp configureServer()
}
}.start(wait = wait)
return server
}
In the above example each time the mcp closure is called (is called once per session) it creates a new Server.
Is this intentional? Is this performant? Is Server designed to be lightweight enough to be instantiated for each session?
Of course I can create the server somewhere else and change the example likeso:
val mcp = configureServer()
fun runSseMcpServerUsingKtorPlugin(port: Int, wait: Boolean = true): EmbeddedServer<*, *> {
printBanner(port)
val server = embeddedServer(CIO, host = "127.0.0.1", port = port) {
installCors()
mcp {
return@mcp mcp
}
}.start(wait = wait)
return server
}
But in this case I cannot find any obvious way to pass the ServerSSESession to the server request.
Is there a way to find it from the coroutine context?
Describe the solution you'd like
I would like to access the ServerSSESession in each Request. This way I will be able to do additional security check (like permissions, etc) for each incoming request.
Describe alternatives you've considered
I couldn't find any alternatives
Additional context
Use the ServerSSESession in a Request
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the Ktor mcp plugin's per-session closure and the ServerSSESession and Request entry points mentioned in the issue. Check how the coroutine context is established for incoming requests and whether the session can be exposed there. Done means each request can access its ServerSSESession for additional security checks, with the shared-server usage clarified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100