ActiveMQ MCP Server
Related Servers
Alternatives to ActiveMQ MCP Server
No user-submitted related servers found.
Related Servers
- AlicenseAqualityAmaintenanceEnables LLMs to declare and manage RabbitMQ AMQP topologies, publish and consume messages, diagnose backlogs, and monitor cluster and connection health through MCP.2093 PyPIApache 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.84 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
- AlicenseBqualityAmaintenanceEnables AI agents to manage RabbitMQ message brokers through admin APIs, supporting multiple brokers, OAuth authentication, and mutative tools.39931 PyPI42Apache 2.0
- AlicenseNot gradedqualityAmaintenanceAn MCP server that enables AI assistants to safely interact with Apache Kafka clusters, providing tools for topic management, message operations, consumer groups, and cluster information.3MIT
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.