was to allow the tool to specify if it is stateful or not
yeah, it makes sense to transform sessions in something optional to avoid the complex state handling, which fits perfect tidewave since the proposal is to have 1:1 server/client connection.
the problem with a general MCP SDK is that some servers may handle N:1 client/server connections, and therefore server is always stateful (also clients!) since we need to keep track of current connections - for server-sent notifications/async responses, also to keep track of server-initiated requests like elicitation (2025-06-18) and sampling/completion (2024-03-11)
for the frame/SSE process location, you can use a registry
currently the transport process handles the SSE channels PIDs, which is very coupled. the problem here is that the server architecture per si became very attached to “single instance” processes, so we should reduce at maximum the state handling, and centralize it, with the rest of parts being just routers/plain code
the implementation of the MCP protocol and the abstraction for defining tools
we kinda already have this clear separation: the handling for server components (tools, prompts and resources) are isolated/plain code execution, apart from the server processes, but we can take this a step further and maybe make the transport and even “session” also plain code instead of stateful processes, that’s would be a big refactor tho.
