-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
Description
I was working for a company to create an MCP server that communicated with RabbitMQ. Then I saw there was no official AMQP support for the MCP. I created a working MCP server that listened to queues, messages as an RPC server and reply to RPC clients.
This works by both creating a new MCP client and a new MCP server type. First, the mcp client sends tool requests to a single queue as an RPC client. This queue is being consumed by the MCP server. When the message is consumed, the MCP server looks at the message body. My proposed idea is using the same JSON RPC 2.0 style body inside the message body. So the MCP server takes the body, looks for the method and params keys exactly the same. tools/call or tools/list all the same logic. Then the MCP server acts as an RPC server, getting the payload and calling tools, listing resources and everything else using its callback function. The callback function returns the result and puts it back on the incoming messsages properties.reply_to queue. That queue is being consumed by the MCP client and receives the message on that queue. The key here is queue listening for the client is not async, so the MCP client awaits a reply from the RPC server before generating a response. The MCP server however can listen to multiple queues from multiple MCP clients, keeping its core functionality the same.
This feature is useful especially for enterprise level technology companies or organizations that use microservice structures. I believe this feature could enhance the adaptation of MCP for larger organizations.
References
No response