Well I’m not really aligned with your conclusions. If we want to implement a tool that is not fast (it searches through database or runs network calls to an Elastic search instance), then all other users will have to wait in line.
Typical handler execution: 10-5000ms (dominated by I/O)
5 seconds is a lot. If you have 3 users using the server at the same time, one user will wait 15 seconds before the calling llm displays anything.
just found the project yesterday, looks amazing! i think this will be the most robust MCP implementation existed!
thanks! i think we need to have some improvements, like for the supervision architecture on-going discussion, protocol negotiation/version alignment too and specially documentation, but im doing my better since im the only active maintainer/core
yeah, but my main point is that MCP is a bidirectional sync communication. there’s no “async response” (kinda emulated with SSE, but not very similar either) i think my main “flaw” on this architecture was to separate the frame (user server state) from the session “generic” MCP server state, since on MCP sessions are not exposed to users actually as they are an internal concept of “client specific connection state”, although hermes aims to have a very similar API/design from LiveView, but we can’t replicate the dynamic behaviour of LiveView since a MCP server is stateful.
the other main problem could be the “base” transport being a single genserver, we may refactor it just to a plain code router and transform the Session one into the main implementor for request handling instead of being just a opaque process holding partial state.
but the major challenge here is that MCP can have multiple different transport layers and although some are more simpler (like STDIO that will have always 1:1 client/server), HTTP based transports can easily have N:1 client/server and if we consider sessions here, this ratio comes to N:N:1 client/session/server with bidirectional/stateful communication, which doesn’t seems to be very simple to architecture. i would like to discuss more and actually ask for help. the last change i did was to at least reduce the bottleneck removing the transport layer from this problem, so it now routes the request async to the Base, which now answers directly to the SSE handler/HTTP connection instead of base->transport->handler, but of course the Base stills have the same problem.
what i would think to “solve” this problem would be:
Base server, transforming into a simple router and maybe removing stateful nature from it. the problem here is that we need to maintain the frame state, which could be changed by the user defined server, so we start to need to handle different frame versions?
i scanned quickly yesterday source code, and it looks impressive. now i’m thinking do i still need my internal Tool implementation that i’m using with elixir agent, or should i standardize everything to hermes-mcp handle_tool logic
hey everyone!
I’m the core maintainer of hermes-mcp, which has grown to 30k+ downloads and 250+ GitHub stars. Since i’m not working anymore on the Cloudwalk org and I’m uncertain about their long-term maintenance plans for the project, I’ve decided to fork and rebrand it as Anubis MCP 
The name Anubis felt fitting - as the Egyptian god of transitions, it seemed appropriate for guiding this project through its own transition. Plus, sometimes you need a deity of change to help you… transition 
If you’re currently using hermes-mcp, I’d encourage migrating to anubis-mcp for guaranteed ongoing support and development.
Repository: GitHub - zoedsoupe/anubis-mcp: Elixir Model Context Protocol (MCP) SDK (hermes-mcp fork) · GitHub
Hex: anubis_mcp | Hex
Would love your continued support and feedback! And now i have more free time to take care about more delicate parts of the project, like documentation ^-^
hi @zoedsoupe , just some feedback on the project based on your architecture:
cool project and nice project name 
hey @ziinc!
frame concept since as i already said on this thread, “session” in the perspective of MCP is an internal technical detail and should not be exposed to users directly (at least the management). we already have a auto-cleanup/auto-close feature tho, but ETS is way better in this case and we could extend it as said on 1. making an interface for whim would to store session on other stores like redis.thanks for the feedback, i’ll be tackling it in the next weeks and i generally agree with all points! also remembering that i forked the original repo to anubis-mcp
