ballerina-activemq-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| mq_validate_brokerA | Check that an ActiveMQ broker is reachable at the given OpenWire URL. Performs a TCP connectivity probe to each endpoint (handles tcp://, ssl://, and failover:(...) forms). When list_destinations is true, also queries the ActiveMQ web-console Jolokia REST agent (default port 8161) to list current queues and topics, degrading gracefully to a TCP-only result if the console is unreachable. Read-only; makes no changes. |
| mq_scaffold_projectA | MAIN tool. Generate a complete, runnable WSO2 Integrator (BI) Ballerina project that integrates with ActiveMQ via the ballerinax/activemq connector. Creates Ballerina.toml (with the connector pinned from the local repository), Config.toml (+ .example, gitignored), .gitignore, main.bal (producer/consumer client demo), listener.bal (the polling-loop carrier with one declarative |
| mq_write_config_tomlA | Write or rotate the broker connection Config.toml for an existing project. Sets the [org.project] table with brokerUrl and (optionally) username/password. Note: the acknowledgement mode and transacted flag live in listener.bal (compile-time annotation), so ack_mode/transacted here are written only as documented mirror comments. Overwrites the existing Config.toml. |
| mq_add_queueA | Add a queue helper module to an existing project: creates modules//.bal with send() and receive() functions wired to the JMS queue (point-to-point). The producer sends with Client.sendMessage(queueName, ..) and receives synchronously with Client.receiveMessage(queueName, timeout). Does not overwrite unless overwrite=true. |
| mq_add_topicA | Add a topic (pub/sub) helper module to an existing project: creates modules//.bal with a publish() function that sends to "topic://". Subscribers are created as Listener services (use mq_add_listener with type=topic, optionally durable=true + subscriber_name). Does not overwrite unless overwrite=true. |
| mq_add_listenerA | Add a message Listener service — the polling-loop carrier — to listener.bal. Generates a declarative |
| mq_set_ack_modeA | Set/update the acknowledgement mode on listener service(s) by editing listener.bal in place. Rewrites sessionAckMode in the @activemq:ServiceConfig annotation and regenerates the affected onMessage to match (adds/removes the activemq:Caller parameter and the acknowledge / commit+rollback calls). Targets one service by service_name, or all services when omitted. Ack mode cannot live in Config.toml (it is a compile-time constant), which is why this edits source. Modifies a .bal file. |
| mq_build_projectA | Run |
| mq_deploy_projectA | Run |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct lifecycle stage or resource type: broker validation, project scaffolding, config writing, queue/topic/listener additions, ack mode editing, build, and deploy. The only similar pair (add_queue vs add_topic) is clearly differentiated by destination type (point-to-point vs pub/sub).
All tool names follow the consistent 'mq_verb_noun' pattern with snake_case throughout. Examples include mq_validate_broker, mq_scaffold_project, mq_add_queue, mq_set_ack_mode, and mq_build_project. This uniform convention makes tool discovery and selection highly predictable.
With 9 tools, the server is well-scoped for its purpose of managing an ActiveMQ Ballerina project lifecycle. The count is neither minimal (which would be vague) nor overwhelming, and each tool serves a clear, necessary function from validation through deployment.
The toolset covers the core lifecycle well: validate, scaffold, add components, configure, build, and deploy. Minor gaps exist such as the lack of a remove/teardown tool or a direct JMS message roundtrip test, but these are not critical for the primary scaffolding workflow and can be worked around via the generated code.