What can you do with this server?

This server provides a comprehensive interface for an AI agent to interact with an ActiveMQ Artemis broker via MCP, covering messaging, queue management, monitoring, and administration. Messaging * Browse messages (browse_messages) — Read messages from a queue without removing them * Send messages (send_message) (admin) — Send a message to an address or queue with customizable body, headers, and properties * Consume messages (consume_message) (admin) — Receive and remove messages from a queue Queue & Address Management * List queues/addresses (list_queues, list_addresses) — Retrieve all queue or address names on the broker * Get queue info (get_queue_info) — View queue configuration (address, routing type, durability, filter, max consumers) * Create queue (create_queue) (admin) — Create a new queue with configurable options * Delete queue (delete_queue) (admin + confirm) — Permanently destroy a queue Monitoring * Get queue stats (get_queue_stats) — View runtime counters (message count, added, acknowledged, expired, consumers, etc.) * Get broker overview (get_broker_overview) — High-level broker status: version, uptime, memory, connection/queue/address counts * List consumers (list_consumers) — See all consumers currently attached to the broker * List connections (list_connections) — See all connections currently open to the broker Administration (admin + confirm required) * Purge queue (purge_queue) — Remove every message from a queue * Move messages (move_messages) — Move messages from one queue to another, with optional filter * Delete messages (delete_messages) — Remove messages matching a filter * Retry DLQ (retry_dlq) — Resend dead-letter queue messages to their original destination Note: The server is read-only by default. Write and administrative tools are only exposed when ARTEMIS_MODE=admin is set. Destructive operations additionally require confirm: true to prevent accidental data loss.

How do I use artemis-mcp-server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@artemis-mcp-server list all queues on the broker" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

artemis-mcp-server

by k-krawczyk

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

artemis-mcp-server

License: MIT

An MCP server that lets an AI agent work with an ActiveMQ Artemis broker. Messaging runs over AMQP 1.0; queue management, monitoring and administration run over the broker's Jolokia REST endpoint.

The server is read-only by default. Tools that change broker state are only exposed when ARTEMIS_MODE=admin, and the four destructive operations additionally require an explicit confirm: true argument so an agent cannot delete data by accident.

Requirements

Node.js 20 or newer
An Artemis broker with an AMQP acceptor and the web console (Jolokia) enabled

Related MCP server: DiceDB MCP

Compatibility

The server uses AMQP 1.0 and the Jolokia REST API rather than a build-specific client, so it is not pinned to one broker release. CI runs the integration suite against these ActiveMQ Artemis versions:

Server	Tested Artemis versions
0.1.x	2.30 – 2.44, and the latest

The server's version is independent of the broker's; there is no need to keep them in step. Older brokers may still work — management calls fall back to legacy Jolokia forms where the API changed — but are unverified, and the server logs a warning at startup when the broker predates the tested range.

Install

Run it directly from a client without installing:

npx artemis-mcp-server

Or install it globally:

npm install -g artemis-mcp-server

Configuration

Configuration comes entirely from environment variables. Missing or invalid values fail fast at startup with a description of what is wrong.

Variable	Required	Default	Description
`ARTEMIS_AMQP_URL`	yes	—	AMQP endpoint, `amqp://host:5672` or `amqps://host:5671`
`ARTEMIS_JOLOKIA_URL`	yes	—	Jolokia endpoint, e.g. `http://host:8161/console/jolokia`
`ARTEMIS_USER`	yes	—	Broker user for both AMQP and Jolokia
`ARTEMIS_PASSWORD`	yes	—	Broker password
`ARTEMIS_BROKER_NAME`	no	`0.0.0.0`	Broker name used in the management ObjectName
`ARTEMIS_MODE`	no	`read-only`	`read-only` or `admin`
`ARTEMIS_MAX_BROWSE`	no	`200`	Hard cap on messages returned by `browse_messages`/`consume_message`
`ARTEMIS_JOLOKIA_TIMEOUT_MS`	no	`10000`	Jolokia request timeout
`ARTEMIS_AMQP_TIMEOUT_MS`	no	`15000`	AMQP connection and operation timeout
`ARTEMIS_LOG_LEVEL`	no	`info`	`error`, `warn`, `info` or `debug`

See .env.example for a starting point. The password is never written to the logs.

Using it with an MCP client

Claude Code (plugin)

This repository is a Claude Code plugin marketplace. Add it and install the plugin; Claude Code prompts for the broker URL, credentials and mode, then runs the server for you:

/plugin marketplace add k-krawczyk/artemis-mcp-server
/plugin install artemis-mcp-server@artemis-mcp

The password is stored in your system keychain.

Claude Code (CLI)

Without the plugin, register the server directly:

claude mcp add artemis \
  --env ARTEMIS_AMQP_URL=amqp://localhost:5672 \
  --env ARTEMIS_JOLOKIA_URL=http://localhost:8161/console/jolokia \
  --env ARTEMIS_USER=artemis \
  --env ARTEMIS_PASSWORD=artemis \
  --env ARTEMIS_MODE=admin \
  -- npx -y artemis-mcp-server

Codex

In ~/.codex/config.toml:

[mcp_servers.artemis]
command = "npx"
args = ["-y", "artemis-mcp-server"]
env = { ARTEMIS_AMQP_URL = "amqp://localhost:5672", ARTEMIS_JOLOKIA_URL = "http://localhost:8161/console/jolokia", ARTEMIS_USER = "artemis", ARTEMIS_PASSWORD = "artemis", ARTEMIS_MODE = "admin" }

Cursor

In .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "artemis": {
      "command": "npx",
      "args": ["-y", "artemis-mcp-server"],
      "env": {
        "ARTEMIS_AMQP_URL": "amqp://localhost:5672",
        "ARTEMIS_JOLOKIA_URL": "http://localhost:8161/console/jolokia",
        "ARTEMIS_USER": "artemis",
        "ARTEMIS_PASSWORD": "artemis",
        "ARTEMIS_MODE": "admin"
      }
    }
  }
}

VS Code

In .vscode/mcp.json (note the servers key):

{
  "servers": {
    "artemis": {
      "command": "npx",
      "args": ["-y", "artemis-mcp-server"],
      "env": {
        "ARTEMIS_AMQP_URL": "amqp://localhost:5672",
        "ARTEMIS_JOLOKIA_URL": "http://localhost:8161/console/jolokia",
        "ARTEMIS_USER": "artemis",
        "ARTEMIS_PASSWORD": "artemis",
        "ARTEMIS_MODE": "admin"
      }
    }
  }
}

Claude Desktop and other clients

Most clients accept the same mcpServers shape as Cursor above. Add the artemis entry to the client's MCP config file (for Claude Desktop, claude_desktop_config.json).

Tools

Tools marked write are hidden unless ARTEMIS_MODE=admin. Tools marked confirm do nothing unless called with confirm: true.

Messaging

send_message (write) — send one message to an address or queue. Arguments: address, body, bodyType (text or bytes, base64 for bytes), subject?, durable?, ttlMs?, messageId?, properties?.
```
{ "address": "orders", "body": "hello", "properties": { "priority": 9 } }
```
browse_messages — read messages without removing them. Arguments: queue, address?, limit?.
consume_message (write) — receive and remove messages. Arguments: queue, address?, count?.

For a named queue on a multicast address, pass both queue and address; the server addresses it as address::queue.

Management

list_queues — names of all queues.
list_addresses — names of all addresses.
create_queue (write) — create a queue. Arguments: name, address?, routingType? (anycast/multicast), durable?, filter?, maxConsumers?, autoCreateAddress?.
delete_queue (write, confirm) — destroy a queue. Arguments: name, removeConsumers?, autoDeleteAddress?, confirm.
get_queue_info — configuration of a queue (address, routing type, durability, filter).

Monitoring

get_queue_stats — runtime counters (message count, added, acknowledged, delivering, scheduled, consumers).
get_broker_overview — version, uptime, memory usage, connection/consumer totals and queue/address counts.
list_consumers — consumers currently attached.
list_connections — open connections.

Administration

purge_queue (write, confirm) — remove every message from a queue.
```
{ "queue": "orders", "confirm": true }
```
move_messages (write, confirm) — move messages to another queue. Arguments: queue, targetQueue, filter?, confirm.
delete_messages (write, confirm) — remove messages matching a filter. A filter is required so this cannot become an accidental purge.
retry_dlq (write, confirm) — resend a dead-letter queue's messages to their original destination.

Security

The default mode is read-only. Granting write access is an explicit choice through ARTEMIS_MODE=admin.
Destructive operations require confirm: true on every call.
Credentials are redacted from log output and stack traces are never returned to the client; unexpected failures surface as a generic message and are logged on stderr.
Jolokia is an administrative surface. In production use a dedicated service account with the least privilege it needs, keep the endpoint off the public network, and prefer TLS for both AMQP and the console.

Development

Start a local broker with the console and Jolokia enabled:

docker compose up -d

Then:

npm install
npm run build
npm test                 # unit tests
npm run test:integration # spins up a broker with Testcontainers; needs Docker

npm run lint, npm run typecheck and npm run format:check round out the checks that CI runs on every push and pull request.

License

MIT

Available Tools

8 tools

browse_messagesBrowse messagesA

Read-only

Read messages from a queue without removing them.

ParametersJSON Schema

Name	Required	Description
`queue`	Yes	Queue name
`address`	No	Address, when it differs from the queue name
`limit`	No	Maximum number of messages to read

Output Schema

ParametersJSON Schema

Name	Required	Description
`queue`	Yes
`count`	Yes
`messages`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces non-destructiveness with 'without removing them'. However, it does not disclose ordering, filtering capabilities, or whether the read is limited to a snapshot vs. live data. The output schema may cover return structure, but behavioral details are minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that efficiently conveys the core action and key property (non-destructive read). Every word adds value, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with full schema coverage and an output schema, the description combined with annotations provides sufficient context. The tool is straightforward, and the absence of edge-case details (e.g., handling of empty queues) is acceptable given the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond 'Read messages from a queue' and does not elaborate on the 'address' parameter or the 'limit' behavior. The schema already handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Read', the resource 'messages', and the key condition 'without removing them'. It effectively distinguishes this tool from siblings like list_queues (which lists queues) and get_queue_stats (which provides statistics), as it focuses on message content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the primary use case (peeking at messages without consumption). While it doesn't explicitly state when not to use or list alternatives, the sibling tool names (e.g., list_queues, get_queue_info) make it clear this is for reading message bodies, not queue metadata.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_broker_overviewGet broker overviewA

Read-only

Return high level broker status and counts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`version`	Yes
`uptime`	Yes
`started`	Yes
`addressMemoryUsage`	Yes
`totalConnectionCount`	Yes
`totalConsumerCount`	Yes
`totalMessageCount`	Yes
`queueCount`	Yes
`addressCount`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds minimal behavioral context. The phrase 'high level broker status and counts' is vague but does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short sentence that efficiently conveys the purpose. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema, the description adequately conveys it returns a high-level overview. No further detail is necessary for such a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters in the schema, so the description does not need to elaborate. Schema coverage is 100% (vacuously). Baseline score for no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'return' and the resource 'high level broker status and counts', distinguishing it from sibling tools that are more specific (e.g., list_queues, get_queue_info).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit usage guidance is provided, but the zero-parameter nature implies it's for a quick broker health check. The description does not specify when or when not to use it versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_queue_infoGet queue infoC

Read-only

Return the configuration of a queue.

ParametersJSON Schema

Name	Required	Description	Default
`queue`	Yes	Queue name

Output Schema

ParametersJSON Schema

Name	Required	Description
`queue`	Yes
`address`	Yes
`routingType`	Yes
`durable`	Yes
`filter`	Yes
`maxConsumers`	Yes
`temporary`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. However, the description contributes no additional behavioral insights, such as what happens if the queue does not exist, pagination, or response content beyond 'configuration', which is vague. With annotations covering the primary behavioral trait, the description adds minimal value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. It is front-loaded with the action and resource. Given the tool's simplicity (one parameter, standard get operation), this level of conciseness is effective and appropriate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the presence of an output schema (which explains return values), the description is incomplete because it does not clarify what constitutes 'configuration'. Sibling tools like get_queue_stats and browse_messages indicate distinct concerns, yet the description fails to inform the agent whether this tool returns settings, limits, or metadata. The agent lacks enough context to predict the exact output beyond the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with one parameter 'queue' described as 'Queue name'. The description does not elaborate on the parameter beyond what the schema already provides. Since schema coverage is high, a baseline score of 3 is appropriate; the description adds no extra semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Return the configuration of a queue' clearly states the verb (return) and resource (configuration of a queue), which distinguishes it from siblings like browse_messages (which browses messages) or list_queues (which lists queues). However, it does not explicitly differentiate from get_queue_stats, which returns queue statistics, so the purpose is clear but not fully distinguished.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like list_queues or get_queue_stats. The description lacks any contextual cues, such as prerequisites or exclusion criteria, leaving the agent without decision support for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_queue_statsGet queue statsB

Read-only

Return runtime counters for a queue.

ParametersJSON Schema

Name	Required	Description	Default
`queue`	Yes	Queue name

Output Schema

ParametersJSON Schema

Name	Required	Description
`queue`	Yes
`messageCount`	Yes
`messagesAdded`	Yes
`messagesAcknowledged`	Yes
`messagesExpired`	Yes
`deliveringCount`	Yes
`scheduledCount`	Yes
`consumerCount`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no behavioral traits beyond stating it returns counters. It does not disclose things like rate limits, authentication needs, or whether counters are instantaneous or cached.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is perfectly concise and front-loaded. Every word is necessary. Zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description does not need to list specific counters. However, it is minimal and could be more complete by noting that counters are for a specific queue and that it is a read operation. Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the 'queue' parameter has 'Queue name' in schema). The description adds no extra meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Return' and the resource 'runtime counters for a queue'. This is specific and distinguishes it from sibling tools like 'get_queue_info' (likely static info) or 'list_queues' (listing names).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or when-not-to-use. With multiple queue-related siblings, explicit usage context is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_addressesList addressesA

Read-only

List the names of all addresses on the broker.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`addresses`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that only names are returned, which is a minor behavioral detail beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundant words, perfectly concise for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema present, no parameters, and annotations covering safety, the description fully covers what the tool does and returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline 4 applies. The description does not add parameter meaning, which is unnecessary given zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists names of all addresses on the broker, with a specific verb and resource. It distinguishes from siblings like list_connections and list_queues.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like browse_messages or get_broker_overview. The description only states what it does without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_connectionsList connectionsA

Read-only

List the connections currently open to the broker.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`connections`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and destructiveHint=false; description adds no additional behavioral traits (e.g., auth needs, rate limits, or what happens if no connections). It aligns with annotations but provides no extra value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no fluff, front-loaded with key action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description is sufficient for a simple list tool with no parameters and an output schema; however, it could specify the type of connections or ordering, but not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so the schema is fully covered by default. Baseline 4 applies per guidelines for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'List' and resource 'connections' with context 'currently open to the broker', distinguishing it from sibling list tools such as list_queues and list_addresses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives; the description does not mention when-not-to-use or compare to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_consumersList consumersA

Read-only

List the consumers currently attached to the broker.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`consumers`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description's addition of 'currently attached' adds mild behavioral context (live state). No other behavioral traits (e.g., pagination, filters) are mentioned, but the tool has no parameters, so transparency is sufficient given simple nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: a single sentence that is front-loaded with the action and resource. There is no extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, output schema present), the description is complete enough. It does not explain return format, but the presence of an output schema compensates. For a more complex tool, it would be insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, so schema coverage is 100%. The description does not need to elaborate on parameter semantics. A score of 4 is appropriate for zero-parameter tools as per guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'consumers' attached to the broker. It is specific and unambiguous. However, it does not distinguish from sibling tools like list_queues or list_connections, though the unique resource name provides natural distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context: use this tool to list consumers. It provides no explicit guidance on when not to use it or alternatives. For a simple list tool, implicit guidance is adequate but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_queuesList queuesA

Read-only

List the names of all queues on the broker.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`queues`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that the tool only returns names, not full details, providing useful behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. Extremely concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, no-parameter list tool with an output schema, the description sufficiently explains the return value (names of all queues). No missing essential context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description does not need to elaborate on parameters; baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists the names of all queues on the broker, with a specific verb and resource. It distinguishes from siblings like browse_messages or get_queue_info, which operate on messages or specific queue details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus alternatives (e.g., get_queue_info or browse_messages). The description lacks context on prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Jun 14, 2026
- First observedbrowse_messages
- First observedget_broker_overview
- First observedget_queue_info
- First observedget_queue_stats
- First observedlist_addresses
- First observedlist_connections
- First observedlist_consumers
- First observedlist_queues

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-06-14 08:25 across 8 tools

Disambiguation5/5

Each tool targets a distinct resource or aspect of the broker (messages, overview, queue config, queue stats, addresses, connections, consumers, queues). No overlapping purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., browse_messages, list_queues) with no mixing of conventions.

Tool Count5/5

8 tools is well-scoped for a broker monitoring and management server, covering core read and listing operations without being excessive or sparse.

Completeness3/5

The tool set covers reading, listing, and status checks well, but lacks write operations such as creating/deleting queues or sending/consuming messages, which are notable gaps for full broker management.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

AgentMarketplace A
io.github.raditotev
MCP Server for an Agent Task Marketplace
Autonomous Agents Agent Orchestration
221
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
Danushkumar-V-mcp-discordOAuth
ai.smithery
An MCP server that integrates with Discord to provide AI-powered features.
Communication Social Media App Automation
2

Related MCP Servers

crypto-sentiment-mcp
Cryptocurrency Social Media Research & Data
kukapay
A
license
A
quality
F
maintenance
An MCP server that delivers cryptocurrency sentiment analysis to AI agents.
Updated a year ago (2025-03-27 22:59 UTC)
5
47
MIT
DiceDB MCP
Databases Developer Tools
pottekkat
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI applications to interact with DiceDB databases.
Updated a year ago (2025-05-18 13:38 UTC)
5
MIT
A2A Client MCP Server
Agent Orchestration Autonomous Agents
tesla0225
F
license
A
quality
D
maintenance
An MCP server that enables LLMs to interact with Agent-to-Agent (A2A) protocol compatible agents, allowing for sending messages, tracking tasks, and receiving streaming responses.
Updated a year ago (2025-04-13 07:21 UTC)
5
28
-
agent-comm
Autonomous Agents Agent Orchestration
keshrath
A
license
Not graded
quality
D
maintenance
MCP server that enables AI coding agents to communicate, share state, and coordinate work in real time via MCP tools or REST API.
Updated 5 months ago (2026-04-17 08:01 UTC)
123 npm
5
MIT