list-queues-vhost
Retrieve all queues within a given vhost in RabbitMQ to inspect queue configurations and statuses.
Instructions
List queues for a specific vhost
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| vhost | Yes |
Retrieve all queues within a given vhost in RabbitMQ to inspect queue configurations and statuses.
List queues for a specific vhost
| Name | Required | Description | Default |
|---|---|---|---|
| vhost | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds no extra behavioral details beyond the annotation's implications, such as permission requirements or result variability, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 6-word sentence, which is concise but arguably too brief for a tool with behavioral and parameter nuance. It front-loads the action but sacrifices detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description should provide minimal completion cues (e.g., vhost format, list scope). It does not, leaving ambiguity for an agent unfamiliar with RabbitMQ conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain the 'vhost' parameter, such as its format (e.g., path '/' or name), leaving the agent without sufficient guidance beyond the schema's type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List queues for a specific vhost' clearly states the verb (list) and resource (queues) with a specific scope, differentiating it from the sibling tool 'list-queues' which likely lists all queues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for a specific vhost), but does not explicitly state when not to use it or mention alternatives. The sibling list provides context, but the description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kmitchell/rabbitmq-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server