ibm-mq-mcp

by moonfruit

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools cleanly separate list/get operations for each resource and message actions are clearly distinct. The main overlap is run_mqsc vs run_mqsc_json, which both execute MQSC but differ by output format and argument style; their descriptions mitigate but do not eliminate potential misselection.
Naming Consistency5/5
All tools use consistent snake_case verb_noun naming: list_* for enumerations, get_* for single-object retrievals, and action_message for messaging operations. The run_mqsc / run_mqsc_json pair follows a clear pattern with a format suffix.
Tool Count5/5
15 tools form a well-scoped administration and messaging surface for IBM MQ: resource queries, message operations, and a generic MQSC escape hatch. Every tool serves a plausible purpose without bloat.
Completeness4/5
The domain is broadly covered: queue managers, queues, channels, subscriptions, topics, messages, and installation info all have query tools, with message put/get/publish/browse operations present. Minor gaps exist—no dedicated get_subscription or get_topic, no direct create/update/delete tools, and browse_message lacks pagination—but run_mqsc fills most gaps.
Average 4.2/5 across 15 of 15 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
Annotations already indicate this is a mutation (readOnlyHint=false), non-idempotent, and non-destructive. The description adds only that the message is a text message and targets a queue; it does not disclose behavioral details like whether the queue must already exist, whether the message is appended, or failure behavior. It provides minimal extra 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?
The description is compact and front-loaded with the core action, followed by a terse parameter list. Every line provides useful information, with no filler or redundancy. The structure makes the purpose and parameters immediately scannable.
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 three-parameter tool with an output schema and annotations covering mutation safety, the description adequately covers the action and all required parameters. It is mostly complete, but lacks guidance on when to use it instead of publish_message, and does not note any prerequisites such as the queue existing.
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?
With schema description coverage at 0%, the description compensates by explaining each parameter in the Args section with concrete examples: qmgr as queue manager name (QM1), queue as queue name (DEV.QUEUE.1), and body as message body. This adds meaning the schema properties lack, though it omits constraints or format details.
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 and resource: '向队列发送一条文本消息' (send a text message to a queue), clearly defining the operation. It also clarifies the message type. However, it does not distinguish this tool from the sibling publish_message, which may also involve sending messages, so it falls short of a 5.
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 alternatives such as publish_message, browse_message, or get_message. There is no mention of exclusions, prerequisites, or contexts where a different sibling should be chosen. Usage must be inferred entirely from the generic action described.
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?
Annotations already convey that this is not read-only, not idempotent, and not destructive, and the description's 'publish' action aligns with those. The description adds that the message is text and targets a topic, but it does not disclose other behavior such as delivery semantics, error conditions, or whether the topic must already exist. No contradiction with annotations is present.
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 compact and front-loaded with the core purpose, followed by a clean Args block. There is no filler or redundant content; every line adds useful information.
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 tool with three required parameters, the description provides enough information to invoke it correctly, and the presence of an output schema means return-value details are not needed. However, it lacks any pointer to how this relates to put_message or other message-writing tools, so the full invocation context is slightly incomplete.
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 0% description coverage, so the description carries the burden of explaining parameters. It does this well by providing each parameter's meaning (queue manager name, topic string, message body) and concrete examples. This is sufficient for an agent to fill in the arguments correctly.
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 action (publish) and a specific resource (a topic), and clarifies that the message is text. It is clear about what the tool does, but it does not explicitly distinguish this from the sibling tool put_message, so it misses the top score.
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 for when to use this tool instead of alternatives such as put_message. The description only provides parameter examples; there is no mention of the intended scenario, prerequisites, or exclusions. An agent is left to infer when publish_message is the right choice.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minor context by saying the tool returns channel definitions, but it does not disclose additional behavioral traits such as filtering semantics, output format details, or any side effects. With annotations carrying the main burden, this is adequate but not rich.
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 compact and well-structured: a one-line purpose statement followed by an Args section. Every sentence earns its place, and the parameter explanations are front-loaded and easy to scan. No redundant or filler content is present.
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 listing tool, the description is largely complete: it states what is listed, names both parameters, and is supported by rich annotations and an output schema. The main gap is the absence of any routing guidance about when to use list_channels versus get_channel or list_queues, which would make the contextual handoff more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate — and it does. It explains qmgr as the queue manager name with a concrete example ('QM1') and defines name as a channel-name filter supporting wildcards with examples ('DEV.*' or '*'). This adds meaningful semantic information that the schema lacks and fully clarifies both parameters.
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 tool's action and resource: '列出通道及其定义' (list channels and their definitions). It is specific enough to distinguish from list_queue_managers and list_queues by name, but it does not explicitly contrast itself with sibling tools like get_channel. Thus it meets the threshold for 'clear but no sibling differentiation'.
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 parameter-level usage details but gives no guidance on when to choose this tool over alternatives such as get_channel or list_queues. It does not state any exclusions or preferred use cases, so the agent is left to infer when this tool is appropriate. This is effectively no usage guidance beyond the basic 'list channels' operation.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds minimal behavioral context by highlighting the returned curdepth field, but does not disclose other behaviors such as error handling or queue-missing scenarios.
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?
Extremely concise: a one-line summary followed by a compact Args block. Every sentence provides value, with the core purpose front-loaded and zero filler.
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 read-only query with two well-described parameters, annotations covering safety, and an output schema available, the description is largely sufficient. The main gap is the lack of explicit routing to sibling tools for listing or other queue operations, but this does not block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining both parameters with meaningful Chinese descriptions and concrete examples ('QM1', 'DEV.QUEUE.1'). This is exactly what the agent needs to supply correct values.
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 a specific action ('query') and resource ('a single queue's all attributes'), including the notable 'curdepth' field. It distinguishes itself from list_queues by focusing on a single queue, though it does not explicitly name siblings.
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?
Usage context is implied by 'single queue' versus siblings like list_queues, but there is no explicit statement of when to use this tool instead of alternatives. No exclusions or prerequisites are 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?
Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds the filtering behavior with wildcard support, but does not disclose additional behavioral details such as pagination, result limits, or error conditions. This is acceptable but not rich.
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, consisting of one clear sentence followed by a clean Args list. Every line serves a purpose, and the core action is 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 list tool with an output schema and clear annotations, the description plus schema covers the essential invocation details: required qmgr, optional wildcard name filter, and read-only behavior. It slightly lacks sibling differentiation and explicit output expectations, but the existing schema and annotations fill the major gaps.
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 0%, so the description carries the documentation burden. It compensates well by explaining both parameters with concrete examples: qmgr is given as 'QM1' and name supports wildcards like 'DEV.*' or '*'. It does not explicitly state that name defaults to '*', though the schema provides that default.
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 action as '列出主题对象' (list topic objects), identifying the specific verb and resource. This distinguishes it from sibling list tools like list_queues and list_subscriptions by naming the exact object type.
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 use when the agent needs to enumerate topics under a queue manager, especially with optional name filtering. However, it gives no explicit guidance about when to prefer this tool over alternatives such as list_subscriptions or how to choose between them.
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?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is well covered. The description adds the returned installation attributes but does not disclose additional behavioral traits such as auth requirements or rate limits. It does not contradict 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?
One short sentence with no filler; the action and result are front-loaded. This is ideal conciseness for a zero-parameter informational getter.
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 no parameters, an output schema present, and annotations covering safety, the description contains everything essential for correct invocation. Additional alternative guidance would be nice but is not required for this simple query 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?
The tool accepts zero parameters, so there is no parameter semantics burden on the description. The 100% schema coverage and zero-parameter surface make this dimension trivially satisfied.
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 states a specific action ('查询' / query) and a specific resource: IBM MQ installation name, version, and platform. This clearly separates it from sibling tools that target queue managers, queues, channels, topics, or messages. The purpose is unambiguous and not a mere restatement of the tool name.
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 when-to-use or when-not-to-use guidance is provided, and no alternative sibling is mentioned. The intended usage is only implied: call this tool when installation-level metadata is needed. This meets the 'implied usage' level but offers no exclusions or alternative routing.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the output includes running status, but it does not disclose other behavioral details such as authentication requirements, rate limits, or error behavior. It does not contradict 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?
The description is a single, information-dense sentence with no redundancy. It front-loads the key action and scope, and every word contributes meaning.
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 zero-parameter simplicity, the presence of an output schema, and read-only annotations, this description fully covers what the tool does and the environment it operates on. No important information is missing for an agent to invoke it 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 zero parameters and the schema is fully covered by an empty properties object. According to the baseline for tools with no parameters, there is nothing for the description to add about parameter semantics, so a 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 states a specific verb ('列出'/'list'), a resource ('queue managers'), a scope ('mqweb server'), and an outcome ('their running status'). This clearly distinguishes it from siblings like get_queue_manager (which targets a single manager) and list_queues (which lists queue objects).
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 it is used to list all queue managers on the mqweb server, but it does not explicitly mention when to prefer this tool over alternatives like get_queue_manager, nor does it state any exclusions. Usage guidance is present only by implication.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that output includes current queue depth, but otherwise discloses no additional behavioral traits such as pagination, ordering, or error behavior.
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 purpose is stated in a single front-loaded sentence, followed immediately by concise parameter documentation. Every sentence earns its place without redundant or vague filler.
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?
With a rich output schema, clear annotations, and complete parameter explanations, the description is sufficiently complete for an agent to call the tool correctly. The only notable gap is the lack of explicit guidance about when to prefer this tool over get_queue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning, and it succeeds. It explains qmgr with an example, name with wildcard patterns, and queue_type with each enum value's meaning and the default, adding substantial value beyond the raw schema.
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 states a specific verb, '列出' (list), and a specific resource, '队列' (queues), while adding the distinct detail that current depth is included. This clearly separates it from sibling tools like list_queue_managers and get_queue.
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 gives filtering guidance through parameters like wildcard support and queue_type, but it does not explicitly say when to use this tool versus alternatives such as get_queue. Usage context is implied by the word 'list' rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解已经提供了 readOnlyHint=true、destructiveHint=false、idempotentHint=true，描述在注解之外额外披露了 name 参数支持通配符过滤（如 DEV.* 或 *），并借助默认值暗示默认列出全部订阅。由于存在输出 schema，未描述返回结构不算明显缺口。
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?
描述非常简短，第一行直接点明功能，随后用两行参数说明覆盖了全部必要信息，没有冗余内容，结构清晰且便于代理快速扫描。
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?
对于只有 2 个参数、1 个必选参数的简单列表工具，描述已经覆盖了调用所需的全部语义；注解覆盖安全特征，输出 schema 负责返回结构，因此没有明显的信息缺失。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
input schema 中没有属性描述（覆盖率为 0%），描述完全承担了参数说明：qmgr 是队列管理器名称并给出示例 QM1，name 是订阅名过滤条件且支持通配符，并给出 DEV.* 和 * 两个示例。两个参数的含义和格式都得到了清晰交代。
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?
描述以明确的动词和资源“列出订阅”说明了工具用途，并结合 qmgr 和 name 参数进一步明确了操作对象是队列管理器中的订阅。但它没有在描述中明确与其他列表类兄弟工具（如 list_queues、list_topics）进行区分，主要依赖工具名称完成区分。
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?
描述通过参数说明了使用场景：必须提供队列管理器 qmgr，可选择 name 进行通配符过滤，因此隐含了“列出指定队列管理器下订阅”的用法。但描述没有说明何时不应使用本工具、是否存在替代工具，也没有给出明确的使用边界。
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?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds that the tool returns complete properties and runtime status, but does not disclose operational details such as error behavior, default fields, or output format. No contradiction with annotations exists.
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 compact and front-loaded: one sentence states the tool's purpose, followed by a brief parameter definition. There is no filler or redundant information, so every sentence earns its place.
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?
For a simple read-only lookup tool with one required parameter, an output schema, and rich annotations, the description is sufficient. It explains what the tool does, what parameter to supply, and the 'single manager' scope, leaving no critical gap for correct invocation.
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 provides no description coverage for the parameter, but the description defines 'qmgr' as the queue manager name and gives a concrete example 'QM1'. This adds meaningful semantic guidance beyond the raw schema for the single parameter.
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 uses a specific verb (查询/query) and a specific resource (单个队列管理器/single queue manager), and explicitly states that it returns the complete attributes and runtime status. This clearly distinguishes it from sibling tools like list_queue_managers.
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 makes clear that this tool targets one named queue manager rather than enumerating managers, which gives an agent clear contextual guidance. It does not explicitly name alternatives or provide when-not conditions, but the single-manager scope is sufficient for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds valuable behavioral context: the operation is irreversible ('无法撤销') and specifically acts on the first message in the queue. This goes beyond the structured hints.
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 short and front-loaded with the key destructive behavior, then the alternative tool, then the parameter explanations. Every sentence earns its place with no filler.
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?
For a simple two-parameter tool with an output schema and annotations covering safety, the description is complete. It tells the agent what happens, that it is irreversible, and when to use the sibling tool instead. No critical information is missing.
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 0%, so the description must compensate. It provides the meaning of each parameter ('队列管理器名称', '队列名称') and concrete examples (QM1, DEV.QUEUE.1), which is adequate but does not add deep semantic detail beyond the parameter names.
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 states a specific verb ('取走') and resource ('队列上的第一条消息'), and clearly explains that the message is removed from the queue. This distinguishes it immediately from browse_message, which is explicitly named as the non-destructive alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides the usage condition: use this tool to consume and remove the first message, and use browse_message when only viewing is desired. This directly routes the agent to the correct sibling tool for the non-destructive case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds meaningful behavioral detail: include_status triggers a CHSTATUS query that may error if the channel is not running, and the status field is always an object (including on failure) for easier parsing. This goes beyond annotations and helps the agent anticipate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a one-sentence purpose summary followed by a clear Args list. Each line earns its place, and the include_status explanation, while detailed, is necessary for correct use. No unnecessary words or repetition.
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 presence of an output schema and clear parameter descriptions, the tool is fully specified for correct invocation. The description covers parameter meanings, optional behavior, and a critical parsing guarantee. Nothing essential is missing for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains all three parameters, provides concrete examples for qmgr and name, and details the include_status behavior including its failure semantics. This gives the agent full understanding beyond the bare schema types.
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 a specific action (查询/query) on a specific resource (单个通道的定义/single channel definition), and notes an optional extension (附带运行状态). It distinguishes from siblings like list_channels by emphasizing 'single', making the selection obvious.
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: use when querying a single channel definition. However, it does not explicitly mention alternatives (e.g., list_channels for listing or get_queue for queues) or state when not to use this tool. The guidance is present but only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds meaningful behavioral context: it can execute arbitrary MQSC, including delete/alter commands, names DELETE QLOCAL as an example, and cautions careful use. No contradiction with 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 compact and front-loaded: purpose, safety warning, alternative guidance, then a clean Args list. Every sentence adds value; no filler or tautology.
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?
For a destructive, general-purpose tool with 6 parameters, it covers the risk profile, alternatives, and all parameters; the output schema accounts for return values. Nothing essential prevents an agent from invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the Args section defines all six parameters with concrete examples: qmgr=QM1, command=display/define/alter/delete, qualifier=qlocal/channel/sub/topic, name supports wildcards, parameters as JSON object, response_parameters as attribute list. This fully compensates for the schema's lack of descriptions.
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?
States a specific verb ('执行 MQSC 命令'), resource (MQSC commands), and key differentiator: returns JSON rather than text. This immediately distinguishes it from the sibling run_mqsc and the specialized list/get tools.
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?
Explicitly says when not to use it: for read-only queries, prefer list_queues/get_queue/list_channels etc., and warns it is destructive like run_mqsc. However, it does not explicitly state when to choose run_mqsc_json over run_mqsc, relying on the first sentence's JSON-differentiator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and not read-only; the description reinforces this by stating it can run modifications/deletions and advising caution. It adds valuable context that arbitrary commands are allowed and gives concrete harmful examples, which goes beyond the annotations without contradicting them.
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 compact and well-organized: purpose, caution, usage guidance, then parameter definitions. Every sentence earns its place, and the most important safety information is front-loaded.
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?
For a tool with only two simple parameters, an output schema, and safety annotations, the description provides all essential guidance: what it does, how to invoke it, what risks exist, and when to choose a different tool. Nothing critical is missing.
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 schema itself has 0% description coverage, but the description compensates with an Args section defining qmgr and mqsc_command, including realistic examples for each. This is sufficient for two simple parameters, though no additional constraints or formats are specified.
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 action: executes a plain-text MQSC command against a specified queue manager. It provides concrete examples (DISPLAY, DELETE QLOCAL, STOP CHANNEL) and positions itself against dedicated query tools, making its role unambiguous and distinct from siblings like list_queues/get_queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly warns that arbitrary MQSC can be executed, including destructive commands, and tells the agent to prefer list_queues/get_queue when only querying is needed. This gives clear when-to-use and when-not-to-use guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses a key behavioral trait: the API has no cursor pagination, so consecutive calls return the same first message. This is valuable context that annotations alone do not convey.
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 tight and well-structured: purpose first, then limitations and alternatives, then parameter documentation. Every sentence carries meaningful information and nothing is redundant.
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's simplicity and the presence of an output schema, the description covers all essential operational aspects: what it does, its restrictions, how it differs from alternatives, and what the two parameters mean. No meaningful gap remains.
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 0%, so the description must compensate. It does by naming both parameters and providing realistic examples (QM1, DEV.QUEUE.1), adding meaning beyond the bare schema titles. It could have included more detail, but for two required string parameters the examples are sufficient.
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 and resource: browse the first message on a queue without removing it. It differentiates from the sibling get_message by explicitly noting that get_message is for taking the message and removing it from the queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when not to use this tool: for iterating an entire queue, use a native MQ client instead; to remove a message, use get_message. It also highlights the REST API limitation of no cursor pagination and repeated results, which directly informs the agent's decision-making.
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

ibm-mq-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![ibm-mq-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/moonfruit/ibm-mq-mcp/badges/card.svg)](https://glama.ai/mcp/servers/moonfruit/ibm-mq-mcp)

Score Badge

Copy to your README.md:

[![ibm-mq-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/moonfruit/ibm-mq-mcp/badges/score.svg)](https://glama.ai/mcp/servers/moonfruit/ibm-mq-mcp)

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/moonfruit/ibm-mq-mcp'

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