i agree but i don’t think its possible to update the title anymore
I’ve adjused the title.
2 Likes
What we did in Tidewave was to allow the tool to specify if it is stateful or not. If it is stateful, it runs within the SSE/frame process and receives the frame state argument. Otherwise, it just runs within its request process. If no tools are stateful, then there is no need for the session ID.
And for the frame/SSE process location, you can use a registry. I would start with Erlang’s built in global.
Finally, I think a MCP library has to solve two separate problems: the implementation of the MCP protocol and the abstraction for defining tools. I would suggest solving them separately. For example, MCP protocol implementation could do all negotiation and then call a module for listing and invoking tools, without actually caring how these tools are defined.
3 Likes
Another Anubis has been recently taking off, in a vaguely related field (MCP ↔ AI, AI ↔ Crawler bots) : https://anubis.techaro.lol/
I don’t have an opinion on an eventual name collision, but thought you might want to know.
yeah, there was this project that kinda conflicts with the project, but i think is ok to to co-exist in this case since anubis-mcp is a language specific sdk/library versus the anubis agnostic/standalone project
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.
1 Like
