ActiveMQ MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.6
Disambiguation2/5
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.
Naming Consistency3/5
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.
Tool Count3/5
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.
Completeness3/5
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.
Average 3/5 across 22 of 22 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on October 1, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. With zero annotations, the description should at least mention whether this is a read-only operation, what it returns, or whether it makes network calls. 'Get detailed information' implies read-only, but nothing about the behavior, error conditions, or what 'detailed' means is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It's a single sentence with zero wasted words. No redundancy or filler. However, it's arguably under-specified rather than concise — there's very little substance to its brevity.
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?
For a tool with one parameter, no output schema, and no annotations, the description is quite thin. It doesn't state what information is returned (configuration, status, metrics), what happens with an invalid connectionId, or how it relates to the ecosystem of connection management tools. Given the sibling tools (import/export/connect/remove/test connections), this tool could use more context about where it fits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning the one parameter (connectionId) is documented in the schema as 'ID of the connection to get info for.' The description adds no additional meaning beyond the schema — it just repeats 'get info.' The description doesn't clarify what format connectionId should take (UUID, name, etc.) or whether it must correspond to an existing connection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it 'gets detailed information about a specific connection,' which is a clear verb+resource. However, it doesn't differentiate itself from sibling tools like list_connections (which presumably lists connections) or connect_broker. The phrase 'detailed information' is vague — what kind of detail? Status, configuration, statistics?
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?
There's no guidance on when to use this tool versus alternatives. It's not clear how this differs from list_connections (all connections vs one) or system_status/broker_info. No exclusions or alternatives are mentioned. The only clue is 'specific' in the tool name itself, which is in structured data, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It doesn't disclose whether existing connections are destroyed, whether import is additive or destructive by default, whether the overwrite flag defaults to false, or any auth/validation requirements. For an import operation that writes to system state, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero waste. It conveys the core purpose efficiently. Though it could be more informative, it doesn't suffer from padding or redundancy.
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?
For a state-modifying import tool with no annotations and no output schema, the description is thin. It doesn't address the format of the 'connections' object, behavior defaults for overwrite, potential for partial failures, or relationship with export_connections. With nested objects and a state-writing operation, more context is warranted to be complete.
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 both parameters ('connections' and 'overwrite') are documented in the schema. The description adds no additional meaning beyond what the schema provides. The 'overwrite' boolean semantics are clear from its own description, and 'connections' is described as the configurations to import. Per the baseline rule for >80% coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Import connection configurations from backup' which identifies a specific verb (import) and resource (connection configurations). However, it doesn't clearly distinguish from sibling 'export_connections' as a counterpart or relate to 'connect_from_config'. The purpose is understandable but the scoping around what 'backup' means is vague.
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 vs alternatives like connect_from_config or list_connections. The description doesn't mention prerequisites (e.g., where the backup comes from, format expected) or which sibling tools would be alternatives for importing vs direct configuration. There's clear context that it's for restoration from backup but no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It merely says 'get' (implying read-only) but doesn't state behavioral details: whether it requires an active connection, what happens if the queue doesn't exist, whether it blocks, or whether it's a safe read operation. For a stats/info tool the read-only nature is somewhat implied but not explicit about edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It's appropriately brief for a simple stats-getter tool, though it could arguably add slightly more detail without becoming verbose.
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?
For a queue information tool with no output schema and no annotations, the description is thin. It doesn't indicate what statistics are returned, whether the queue/connection must pre-exist, or distinguish its scope from sibling tools like broker_info and broker_stats. The 2-param schema is simple, but the tool's return value and usage context are unspecified.
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%, with both queueName and connectionId having descriptions in the schema. The description adds nothing beyond the schema—it doesn't explain the relationship between the two params or expected formats. Baseline 3 applies since the schema fully documents both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get queue statistics and information' which names the verb (get) and resource (queue statistics/information). It's reasonably clear but generic—it doesn't specify what statistics are included (message count, consumers, depth, etc.) or how it differs from sibling tools like list_queues, broker_stats, or broker_info which could overlap in purpose.
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. With siblings like broker_stats, list_queues, broker_info, and health_status, there's ambiguity about which tool retrieves which level of metrics (queue-level vs broker-level). The description offers no context about when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Subscribe' implies a blocking/waiting operation, but the description doesn't state how long it blocks, whether it returns immediately with available messages, or what behavior the timeout/maxMessages parameters trigger. Since it's a messaging operation (not explicitly read-only or destructive), more detail is needed about its runtime semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that states the core action with no fluff. It's appropriately concise given the schema already covers parameter details. The brevity is not a fault in itself, though it could have used the saved space for more behavioral detail.
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?
Given this is a subscription tool with no annotations and no output schema, the description needs to convey more about the blocking behavior, return format, and relationship to batch consumption. The presence of publish_message (opposite) and consume_message (related sibling) in the tool list means the description should differentiate these, but it doesn't. A subscription tool typically has nuanced semantics (blocking, long-polling, delivery guarantees) that are entirely unspecified.
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 schema already documents all four parameters (connectionId, topicName, timeout, maxMessages). The description adds no parameter-specific information beyond what the schema provides. Baseline 3 is appropriate since the schema carries the heavy lifting and the description aligns with it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb+resource clearly ('Subscribe to a topic and receive messages'), which is a specific action that distinguishes it from siblings like publish_message and send_message. However, it doesn't explain what happens with the received messages or how they're returned, leaving the core purpose somewhat underspecified for a blocking subscribe operation.
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 vs alternatives. Since there are sibling tools like consume_message, browse_messages, and publish_message, the tool needs to clarify its role (e.g., long-poll subscription versus one-shot consumption) to help the agent choose correctly. No exclusions, prerequisites, or alternative tool references are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description is purely a statement of function with no mention of what gets returned, whether it requires prior connection, what happens on invalid connectionId, or performance characteristics. For a read-only list operation this is a minimal gap, but with zero annotation coverage there's no safety signal at all.
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 efficient sentence with zero waste. It front-loads the verb and resource and clearly conveys the core function. Very concise.
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?
For a simple single-parameter list tool, the description is arguably adequate at a surface level. However, with no output schema, no annotations, and no return format information, the agent cannot know what the result looks like or how to interpret failures. For a tool operating on connections (thematically similar to other connection-related tools), slightly more context about expected behavior would be warranted.
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 only parameter, connectionId, is described as 'ID of the connection to list topics for.' The description adds nothing beyond the schema, but the baseline is 3 when schema already fully documents parameters. No additional format, constraints, or behavioral context is added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all topics for a connection' with a clear verb (list), resource (topics), and scope (all topics for a connection). It's a specific purpose but doesn't distinguish itself from the sibling tools like list_queues or subscribe_topic, so its differentiation relies entirely on the name itself.
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?
There is no guidance on when to use this tool versus alternatives. Sibling tools like list_connections and list_queues exist, and the description doesn't clarify whether this is for listing only subscribed topics vs all available topics, or how it differs from related tools. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get broker statistics and health information' implies a read-only operation, which is reasonably inferable. However, it doesn't state what specific statistics or health data are returned, whether the call can fail for disconnected/missing connections, or any response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It's appropriately brief for the tool's simplicity. No redundancies or filler.
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?
For a single-parameter info-gathering tool with no output schema, the description is thin. It doesn't explain what 'statistics' includes, what 'health' refers to, or how this differs from the many overlapping sibling tools (broker_stats, health_status, system_status, connection_info). Given the competitive tool landscape, more context is needed for correct selection.
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?
The single parameter connectionId is fully documented in the schema (100% coverage), so the schema carries the semantic weight. The description adds no additional meaning about the parameter beyond what the schema states. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair ('Get broker statistics and health information'), but it's somewhat ambiguous against siblings. With sibling tools 'broker_stats' and 'health_status' both present, this description doesn't clearly distinguish what broker_info uniquely provides versus those. The verb is clear but the scope differentiation is missing.
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 'broker_stats', 'health_status', or 'system_status'. With several closely related sibling tools (broker_stats, health_status, system_status), the description provides no differentiation or exclusion criteria. The agent is left guessing which tool to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, whether it performs live network checks or returns cached status, what happens if a connection is down (error vs. degraded status), or whether it requires an active broker. For a health-check tool with zero annotation coverage, the description offers minimal insight into behavior beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no waste. It's appropriately terse for a 0-parameter tool. Minor deduction because it could have added one clause about what 'health' measures without bloating the text.
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?
For a tool with 0 parameters, no output schema, and no annotations, the description is fairly minimal. 'Get health status of all connections' tells the agent what it does but leaves open questions: what does health status look like (boolean, metrics?), does it check connectivity live, and how does it relate to test_connection? Given the rich sibling context (test_connection, connection_info, system_status), more clarity on scope and output would help the agent select correctly.
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 tool has 0 parameters, so there is no schema to compensate for. A 0-parameter tool gets a baseline of 4, and the description appropriately tells the agent what the tool covers ('all connections'), which is meaningful since it could have been scoped to a single connection. No parameter ambiguity exists to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get health status of all connections' with a clear verb (get) and resource (health status of connections). It distinguishes somewhat from siblings like list_connections and system_status, but 'health status' is ambiguous—it doesn't clarify what 'health' means (e.g., connectivity, latency, last heartbeat). The purpose is clear enough to be distinguished from list_connections but lacks specificity about what health entails.
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. Among siblings there are test_connection, connection_info, system_status, and broker_stats, all of which could overlap with 'health status'. The description does not explicitly say when to prefer this over test_connection or system_status, nor does it note prerequisites (e.g., must connections exist first?) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It doesn't mention what metrics are returned, whether this is a read-only operation (though 'get' implies it), what granularity of data is provided, or whether it covers broker/connection/queue health all together or only the local system. The description leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. It front-loads the purpose clearly. While it could benefit from additional context about scope and differentiation, it achieves conciseness effectively.
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?
For a 0-parameter tool with no output schema, the description is quite thin. 'Overall system status and performance metrics' doesn't specify what subset of the system (broker, queues, connections?) is covered, what performance metrics are included, or what the response format looks like. Given the presence of related tools (health_status, broker_stats), more contextual detail is needed to disambiguate and set expectations.
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 tool has 0 parameters, and schema description coverage is 100% (trivially, since there are no parameters to document). Per the rubric, a 0-param tool gets a baseline of 4. The description aligns with the empty schema and there's no parameter confusion possible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get overall system status and performance metrics' with a clear verb+resource ('get' + 'system status'), but it does not distinguish this from the sibling tool 'health_status' which likely covers similar ground. The purpose is clear enough but there's potential overlap with sibling tools that isn't addressed.
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 when-to-use guidance is given. There's no distinction between this tool and the semantically similar siblings like 'health_status' and 'broker_stats'. The description doesn't explain when an agent should choose system_status over these alternatives, creating ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does not disclose what happens on failure, whether the connection must be active, whether publishing creates the topic if it doesn't exist, persistence guarantees, or any side effects. For a message publication tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It efficiently communicates the core action, though it could arguably be slightly longer to cover behavioral details without losing its tight structure.
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?
For a tool with no output schema and no annotations, the description should compensate with more behavioral and contextual detail. It does not mention whether the topic must already exist, whether the message is serialized in a particular format, error conditions, or the return behavior. Given the nested headers object and zero annotation/ouput-schema coverage, this is under-specified.
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 schema already documents all four parameters (headers, message, topicName, connectionId) with descriptions. The tool description itself adds no parameter-level semantics, but with full schema coverage the baseline is 3. The nested 'headers' object lacks detail about expected key-value types within the schema, but the description doesn't address that either.
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 'Publish a message to a topic' uses a specific verb (Publish) and resource (topic) to convey the core action clearly. It distinguishes from the sibling 'send_message' adequately but does not explicitly differentiate, and there are several related tools (subscribe_topic, list_topics) that share topic context, so while clear it doesn't fully set itself apart.
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. Notably, there is a sibling tool 'send_message' whose exact relationship is unclear - are they the same, or one for queues vs topics? The description offers no context on when to choose publish_message over send_message or how it differs from consuming/browsing messages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does not state that this is a destructive/irreversible operation, that a confirm flag is required for safety, whether it removes messages being currently processed, or what happens to the queue afterward. The confirm parameter implies destructive behavior but the description relies on schema rather than disclosing it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. However, given the destructive nature of the operation, a bit more behavioral context would justify additional length.
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?
For a destructive tool with no annotations and no output schema, the description is notably thin. It doesn't disclose that all messages (including possibly in-flight ones) are removed, doesn't mention the confirm safety flag purpose, doesn't note irreversibility, and provides no guidance on impact to connected consumers.
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 all three parameters (confirm, queueName, connectionId) are already documented structurally. The description adds minimal value beyond this—it doesn't explain why confirm must be true, what the queueName semantics are, or how connectionId relates to the connection lifecycle.
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 'Remove all messages from a queue' uses a specific verb (Remove) + resource (queue) and clearly states the scope (all messages). It distinguishes from siblings like consume_message or browse_messages, though it doesn't explicitly differentiate from any similar purge/delete tool in the siblings list.
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 given on when to use this tool vs alternatives. There's no mention of destructive nature, no confirmation about whether this is reversible, no notes about prerequisites (e.g., connecting first), and no warnings that this is a destructive operation affecting all consumers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. 'Remove' implies a destructive mutation, but the description doesn't state whether removal is reversible, whether it disconnects active sessions, whether it affects dependent consumers/producers, or if it requires special permissions. For a destructive operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. However, it's arguably under-specified for a destructive operation, though conciseness itself is excellent.
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?
For a destructive single-parameter tool with no annotations and no output schema, the description is too thin. It doesn't explain side effects of removing a connection, whether it impacts existing message flows, or what the result/confirmation looks like. Given the simplicity of the parameter, completeness could be higher with a couple of behavioral notes.
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% for the single 'connectionId' parameter, which the schema documents as 'ID of the connection to remove.' The description adds no additional semantics beyond what the schema provides, so baseline 3 is appropriate given full schema coverage.
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?
Clear verb+resource: 'Remove an ActiveMQ broker connection.' It distinguishes from siblings like list_connections (listing) and connect_broker (creating/connecting), but doesn't explicitly name a differentiating alternative. Purpose is clear and specific.
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 when-to-use guidance, no statement about when NOT to use this (e.g., versus disconnect vs. purge). No context about whether the connection needs to be inactive first or whether removal affects running operations. Implied usage only from the verb 'remove'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether a connection must be established first, whether sending is synchronous or returns a receipt, potential failure modes, or whether the message is durable. For a send operation with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero waste. It's appropriately short given that the schema documents the parameters. Efficient but on the edge of being too minimal.
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?
This is a messaging tool with 4 params and no annotations or output schema. The description only states the action but doesn't explain behavioral expectations around the connection lifecycle, delivery guarantees, or return values. Given the sibling set includes publish_message and consume_message, some guidance on how this differs would materially improve completeness.
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 all four parameters are individually documented in the schema. The description itself adds little beyond the schema. The destination parameter already explains the /queue/ and /topic/ conventions. Baseline 3 is appropriate since the schema handles the heavy lifting.
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 uses a clear verb+resource pattern: 'Send a message to a queue or topic'. It names the primary resource and the action. However, it doesn't distinguish from closely related siblings like publish_message or consume_message, which weakens sibling differentiation slightly.
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 given on when to use send_message vs alternatives like publish_message (which appears to be a sibling for publishing to brokers). There's no context about prerequisites (e.g., whether a connection must be active), nor exclusions. The description gives no usage context at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state what happens on failure, whether authentication is attempted, whether this is a read-only check or establishes state, what the return result looks like, or whether it mutates any connection registry state. For a test tool that could have side effects (e.g., adding a connection to a registry), this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with the core purpose. It's minimal but adequate for a simple test utility. Could have added a bit more context without bloating, but as written it is appropriately concise.
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?
For a tool with 4 parameters, no annotations, and no output schema, the single-sentence description is insufficient. It doesn't explain expected return values (success/failure output), how this differs from health_status or system_status, whether the test is synchronous with a timeout, or how authentication parameters factor into the test. Sibling tools like connect_broker, system_status, and health_status create ambiguity that this description fails to resolve.
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 schema already documents all four parameters including defaults and descriptions. The description adds no parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate since the schema handles the heavy lifting, though the description doesn't clarify how username/password relate to the port default (web console port vs. broker protocol port), which could cause misconfiguration.
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 'Test connectivity to an ActiveMQ broker' uses a specific verb (test) and resource (connectivity to broker), clearly stating purpose. However, it doesn't distinguish from siblings like system_status or health_status, which may also assess connection health, though those more likely target the broker's operational status rather than connectivity.
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 system_status, health_status, or connect_broker. The tool appears to be a connectivity check, but the description doesn't clarify whether it establishes a persistent connection, whether credentials are needed for testing, or when users should prefer connect_from_config or connect_broker instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It is a read operation that presumably lists queue names, but it does not disclose what data each returned queue entry contains, whether listing requires active/connected state, or whether there could be errors (e.g., invalid connectionId). Coverage of behavioral traits is 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, focused sentence with no waste. Every word earns its place, and it front-loads the core action. This is appropriately concise for a simple single-parameter list tool.
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?
With 1 parameter, 100% schema coverage, no output schema, and no annotations, the tool is simple. The description is arguably sufficient for a minimal list operation given the schema covers the only parameter. However, absence of any note about return shape or error/connection requirements leaves slight room for improvement, so a 3 is fitting.
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?
Schema description coverage is 100%, meaning the schema already documents connectionId thoroughly. The description adds the conceptual framing that it lists queues 'for' the connection, which aligns with the parameter. Since the rule states high schema coverage (>80%) gives a baseline of 3 and the description modestly reinforces the param's role, a 4 is justifiable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('List all queues') but only scopes it to 'a connection' without specifying which connection type or adding context that distinguishes it from sibling tools like list_topics or queue_info. It is adequate but does not differentiate the tool's specific role among the many peer tools.
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 gives no guidance on when to use this tool versus list_connections, queue_info, list_topics, or other sibling tools. There is no mention of prerequisites (e.g., connection must be active), no alternates named, and no exclusions. The usage context is entirely implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description says 'Connect' implying an active session is established, but it doesn't state whether this mutates state (e.g., persists a connection registration), what happens on failure, whether it verifies the broker before connecting, or what the return value/callback looks like. With sibling tools like test_connection and connect_broker existing, the behavioral semantics (is this just opening a session, or actually registering a persistent connection?) are ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that conveys purpose and key context. No wasted words, front-loaded with the action. It earns its place, though it could arguably be slightly more informative given its brevity.
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?
For a connection-establishing tool with no annotations and no output schema, the description is thin. It doesn't explain side effects (does this persist a connection or just open it?), lifecycle (does the connection need removal via remove_connection?), error behavior, or how to verify success (is there a returned ID, or should the agent check connection_info?). Given there are 22 sibling tools including connection lifecycle and status tools, the description leaves too much room for the agent to guess about what 'connect' actually accomplishes.
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%, so both parameters (configName and connectionId) are documented in the schema itself. The description adds 'from config file' context that implies configName refers to a named entry in a config file, which is slight added value beyond the schema. However, the description doesn't clarify the interaction between configName and connectionId beyond what the schema defaults already state. Baseline 3 is appropriate given full schema coverage.
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 states a specific verb+resource: 'Connect to an ActiveMQ broker using a named configuration.' This clearly distinguishes it from siblings like 'connect_broker' (which likely uses explicit broker params) and 'list_connections'/'connection_info' (read operations). The 'named configuration' qualifier is the key differentiator from connect_broker.
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 ('named configuration from config file') but there is no explicit when-to-use vs alternatives guidance. It doesn't explicitly say to use connect_broker when you have direct broker parameters, or how this relates to import_connections. The implied context is clear but no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Consume' strongly implies the message is removed from the queue once read, but the description doesn't state this destructive behavior, the blocking nature of the call, or consequences of a timeout. The autoAck default of true implies automatic removal, but this is never disclosed in the text. For a tool that mutates queue state, this is a significant transparency gap.
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, direct, complete sentence with zero wasted words. It states the essential purpose without fluff. This is appropriately concise for a single-line tool description.
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?
Given 6 parameters, no output schema, and no annotations, the description is under-specified. It fails to disclose the blocking semantics, timeout behavior's effect on return (null vs error), whether consumption is destructive, and the meaning of the return value (returned message body). Without an output schema, the absence of return-format information is more impactful. For a queue-consuming tool with these complexities, more behavioral context is needed.
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?
Schema description coverage is 100%, so the schema already documents all 6 parameters well, giving a baseline of 3. The description doesn't add syntactic detail, but the schema's parameter descriptions carry clear meaning (timeout in ms, auto-ack behavior, client ID for persistent sessions). No format ambiguities remain, so the schema suffices. A 4 is warranted since the schema documentation is thorough enough that the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Consume a message from a queue' uses a specific verb (consume) and resource (message from a queue), making the core purpose clear. However, it doesn't distinguish itself from siblings like browse_messages or send_message beyond the consumption semantics, which is arguably inherent. It's clear but provides no deeper disambiguation of what 'consume' means (destructive read vs peek).
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 (consuming from a queue) but offers no explicit guidance on when to choose this over alternatives like browse_messages (non-destructive reads) or send_message. It doesn't state prerequisites (e.g., an active connection) or contextual scenarios where this tool is appropriate. No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. Connecting to a broker is a state-changing operation, yet the description doesn't mention whether it validates the connection, what happens on failure, whether it establishes persistent state (given connectionId), or how it relates to other connection-related tools. It also doesn't note authentication/reconnection behavior even though those parameters exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no filler. It's appropriately brief, though the 'with manual configuration' clause could arguably be doing more differentiation work that's currently heuristic.
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?
This is a connection management tool with 7 parameters, no output schema, and no annotations. For a tool that establishes a connection (likely with side effects and authentication implications), the description provides minimal context. It doesn't explain what a successful connection does, what the connectionId is used for, how reconnection settings feed in, or how this differs operationally from connect_from_config. With several closely related sibling tools, this needs more detail to guide correct selection.
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?
Schema coverage is 100%, so the schema documents all 7 parameters. The description references 'manual configuration' which frames the parameters as user-supplied manual settings, adding a bit of context to the parameter group. However, the description adds little per-parameter meaning beyond what the schema descriptions already provide, though the baseline 3 is lifted slightly by the framing.
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 'Connect to an ActiveMQ broker with manual configuration' uses a clear verb (Connect) and resource (ActiveMQ broker), and distinguishes itself with 'manual configuration' which implies contrast with connect_from_config (likely config-file based). However, it doesn't explicitly differentiate from siblings beyond this one phrase.
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 phrase 'manual configuration' implies this is for manual setups versus importing/config-file approaches, suggesting an alternative exists. But it doesn't explicitly state when to use it vs connect_from_config or import_connections, nor when not to use it. The differentiation is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It doesn't disclose what format the export takes (file? JSON?), where output goes, whether it requires permissions, whether it affects live state, or what the response looks like. For an export tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no wasted words. It's appropriately brief given there are no parameters to describe, though it could arguably add format details without growing much.
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?
There is no output schema and no annotations, so the description must cover behavior and results. It doesn't explain what the export produces, its format, or how it relates to the inverse import tool. For a tool with zero params and no schema support, the description leaves important behavioral questions unanswered, though the simple signature lowers the bar somewhat.
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 0 parameters and the schema has 100% coverage (empty properties object), so there's nothing for the description to document. The schema fully defines the parameter surface, giving a baseline 4.
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 states a specific verb+resource ('Export connection configurations') with a clear purpose ('for backup or migration'). It distinguishes reasonably from siblings like import_connections (the inverse) and connect_from_config (which loads into the live system), though it doesn't explicitly name the alternative.
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 ('backup or migration') which signals when to use this tool — when you need to persist or transport configs. However, it doesn't explicitly state when NOT to use it or contrast with import_connections/connect_from_config, leaving the agent to infer the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation, but doesn't disclose whether this aggregates data across brokers, what happens if no connections exist, whether it's expensive/slow, or what the return format looks like. Given no annotations at all, a modest score is appropriate but it does state it covers 'all connections' which adds some scoping context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action verb. No wasted words. It could arguably add 'returns aggregated statistics across all configured brokers' but as written it's efficiently compact.
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?
The tool has no input schema, no output schema, and no annotations, so the description must carry all explanatory weight. 'Comprehensive broker statistics' is vague—it doesn't say what statistics are included (e.g., messages, connections, throughput, errors). For a tool with zero structural metadata, more specificity about what 'comprehensive' entails would be needed for full completion.
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?
This tool has zero parameters, and with 100% schema coverage (trivially, since there are no parameters), the dimension is satisfied. The description doesn't need to explain any parameters. Baseline 4 is appropriate for a 0-param tool since there is nothing to compensate for.
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 'Get comprehensive broker statistics for all connections' uses a specific verb ('Get') with a clear resource ('broker statistics') and scope ('for all connections'). It distinguishes reasonably from siblings like system_status and health_status which suggest different scopes, though 'comprehensive' is somewhat vague about what statistics are actually included.
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 health_status, system_status, or broker_info. The description does not mention when this aggregating view would be preferred over per-connection or per-broker tools, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. The key behavioral trait (non-consuming read) is explicitly stated, which is valuable. However, it doesn't disclose whether messages remain available after browsing, whether browsing affects message locks or visibility timeouts, or whether results are ordered/deduped. For a read operation with no annotations, this is partially disclosed but incomplete.
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, dense sentence that communicates purpose and the key distinguishing trait (non-consuming) with zero wasted words. Front-loads the core action and constraint efficiently.
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?
This is a relatively simple tool (3 params, no output schema, no nested objects). The description covers the core purpose and distinguishing behavior. However, with no output schema and no annotations, it would benefit from describing the return format (array of message bodies/headers), ordering, or whether browed messages are locked. Adequate but with clear gaps given the absence of annotations and output 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%, so the schema documents all three parameters (connectionId, queueName, limit). The description adds no additional parameter semantics beyond what the schema provides—for example, it doesn't clarify limit defaults or behavior (does limit 0 mean no limit?). Baseline 3 is appropriate since schema handles the heavy lifting.
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 'Browse messages in a queue without consuming them' uses a specific verb+resource (browse messages in a queue) and adds a critical distinguishing feature: non-consuming behavior. This clearly distinguishes it from sibling consume_message, though it doesn't name the alternative explicitly.
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 'without consuming them' phrasing implicitly signals when to use this versus consume_message, contrasting peek-style reading versus destructive consumption. However, it doesn't name the alternative tool, discuss when NOT to use it, or clarify whether a non-consuming browse is the right choice for inspection workflows or if consume is needed for actual processing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'List all configured... connections' strongly implies a read-only, non-destructive operation. However, it doesn't disclose what format the return takes, whether it reports connection health/status, or what 'configured' means (persisted config vs. active/live sessions) — which matters given sibling tools like connection_info and system_status.
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 declarative sentence with zero wasted words. Fully front-loaded with the key verb and resource. Ideal conciseness for a parameterless listing tool.
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 zero-parameter read-only list tool, this is nearly complete. The only minor gap is defining what 'configured' means (persisted config vs. active connections) and clarifying overlap with connection_info, but the description is otherwise sufficient for an agent to select and invoke correctly.
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?
Tool has 0 parameters with 100% schema coverage — nothing to document. Baseline 4 for zero-parameter tools is appropriate since there's no parameter gap to compensate.
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?
Description uses specific verb+resource ('List all configured ActiveMQ broker connections'). It's clear and distinguishable from siblings like test_connection, connection_info, and import_connections which imply different operations.
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?
Description implies it's a read-only listing operation with no parameters needed. However, it doesn't explicitly state when to use this vs. alternatives like connection_info or system_status, nor does it note other operations that might also list connection-related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It clearly states this is a read-only listing operation ('Show all...configurations available in the config file'), which implies non-destructive behavior. However, it doesn't disclose what the output looks like, whether it reads from a local file or remote service, or any auth/permission requirements.
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 focused sentence that conveys the purpose, scope ('all...in the config file'), and the integration context (usable with connect_from_config). Zero waste, appropriately 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?
This is a simple zero-parameter listing tool with no output schema. The description sufficiently conveys purpose, scope, and the relationship to connect_from_config. Minor gaps include not describing the return format or whether it reports configs from a default location.
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 tool has 0 parameters and 100% schema coverage, so the schema is trivially complete. Per the rubric, 0 parameters earn a baseline 4. The description's reference to which configurations are shown ('that can be used with connect_from_config') adds meaningful selection context beyond what an empty schema conveys.
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 uses a specific verb ('Show') with a clear resource ('ActiveMQ broker configurations') and explicitly ties the purpose to 'available in the config file that can be used with connect_from_config'. It clearly distinguishes this from siblings like connect_from_config itself, list_connections, and import_connections.
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 explicitly states the use case: retrieving broker configurations that can be used with connect_from_config. This gives the agent clear context for when to invoke it vs. the sibling connection tools. It doesn't explicitly name alternatives or exclusions, but the tie to connect_from_config provides applicable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![activemq-mcp-server MCP server](https://glama.ai/mcp/servers/mradovic95/activemq-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/mradovic95/activemq-mcp-server)

Score Badge

Copy to your README.md:

[![activemq-mcp-server MCP server](https://glama.ai/mcp/servers/mradovic95/activemq-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/mradovic95/activemq-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mradovic95/activemq-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server