ActiveMQ MCP Server
Related Servers
Alternatives to ActiveMQ MCP Server
No user-submitted related servers found.
Related Servers
- 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.813 npm1MIT
- AlicenseBqualityAmaintenanceEnables AI agents to manage RabbitMQ message brokers through admin APIs, supporting multiple brokers, OAuth authentication, and mutative tools.3988 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
- FlicenseCqualityDmaintenanceExposes Kafka administration operations as MCP tools, enabling AI agents to inspect Kafka clusters using natural language.1-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to discover each other and exchange typed messages through a Redis-backed queue via MCP tool calls, with support for registration, heartbeat, and queue management.2MIT
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.