ActiveMQ MCP Server
Related Servers
Alternatives to ActiveMQ MCP Server
No user-submitted related servers found.
Related Servers
AlicenseNot gradedqualityBmaintenanceEnables AI assistants to connect to JMS brokers such as IBM MQ, ActiveMQ, Artemis, RabbitMQ, TIBCO, Solace, and WebLogic, browse queues non-destructively, inspect messages and queue depth, and optionally send or consume messages when read-only safeguards are disabled. It auto-discovers JMSToolBox configurations and loads broker client drivers dynamically.25 npm1Apache 2.0- AlicenseAqualityBmaintenanceEnables LLMs to declare and manage RabbitMQ AMQP topologies, publish and consume messages, diagnose backlogs, and monitor cluster and connection health through MCP.20Apache 2.0
- FlicenseAqualityBmaintenanceEnables LLM clients to interact with IBM MQ by exposing management and messaging REST APIs as 15 MCP tools, covering queue manager queries, MQSC commands, object inspection, and message send/receive operations.15-
- AlicenseAqualityCmaintenanceAn MCP server that lets an AI agent work with an ActiveMQ Artemis broker.811 npm1MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to query system health, metrics, service reconnaissance, run multi-node patrols, and send incident alerts across distributed infrastructure through MCP tools.ISC
- AlicenseBqualityCmaintenanceEnables AI agents to manage RabbitMQ message brokers through admin APIs, supporting multiple brokers, OAuth authentication, and mutative tools.39272 PyPI43Apache 2.0
TDQS
Scored across 22 tools
Several tools have overlapping purposes that could cause misselection. connect_from_config, connect_broker, and test_connection all involve establishing/testing broker connections. health_status, system_status, broker_info, and broker_stats all report on system/broker health and metrics with unclear boundaries. An agent would struggle to pick the right one.
Most tools follow a verb_noun pattern (list_queues, send_message, purge_queue, export_connections), which is reasonable. However, there are deviations: show_config, system_status, broker_info, and connection_info use different structures, and the mixed usage of 'get' vs 'info' (queue_info vs broker_info) is slightly inconsistent.
At 22 tools, the surface is on the heavy side but not unreasonable for a broker management server. However, there is significant redundancy (broker_info, broker_stats, system_status, health_status overlap heavily; connect_from_config vs connect_broker), suggesting the count could be trimmed to ~14-16 tools without losing capability.
The server covers connect/disconnect, configuration management, queue operations (create... actually missing create_queue/delete_queue), messaging (send/consume/browse/publish/subscribe), and health monitoring. Gaps include queue/topic creation and deletion, message deletion for specific messages, and topic-specific management beyond publish/subscribe. The browsing+purge flow partially covers message lifecycle but lacks fine-grained control.