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

No annotations are provided, so the description carries the full burden, and it does disclose one meaningful behavioral trait: the operation is gated by the global write-protection flag (--allow-write). It does not state idempotency (what happens if the binding already exists), required permissions, or whether the operation is reversible — significant gaps for an unannotated mutation tool.

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 purpose sentence is front-loaded and the @param list is efficiently formatted, with no padding. The param block is justified given the 0% schema coverage, though the header ordering of the write-gate note before the params is slightly awkward.

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?

An output schema exists, so the description needn't detail return values and only points at the binding report, which is fine. Combined with full parameter documentation and the disclosed write gate, it covers what an agent needs for this mutation tool, though it could say more about failure/idempotency behavior given the absence of annotations.

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?

Schema description coverage is 0%, so the description must compensate, and it does: it documents all five parameters with meaning and defaults (routing_key defaults to empty, connection defaults to 'default', arguments is optional). The only shortfall is that 'arguments' is left as a vague 'optional binding arguments' with no hint about its expected shape.

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?

States a specific verb+resource: binding a queue to a named exchange with a routing key. The verb 'bind' clearly separates it from siblings like rabbitmq_unbind_queue and rabbitmq_list_bindings. It does not, however, explicitly name those alternatives, so it stops short of full sibling differentiation.

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?

Usage is implied by the clear 'bind' verb and the mention of the global write gate, which tells the agent this is a write operation. But there is no explicit when-to-use/when-not guidance and no reference to unbind_queue or list_bindings as alternative choices.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the write-gate constraint and the default for each option, but omits key mutation semantics: whether re-declaring an existing exchange is idempotent, what happens on a conflicting declaration, and whether failures raise errors. Return value is covered by the @return note and an output schema exists.

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 purpose and the write-gate constraint are front-loaded in the first two lines, followed by a compact @param list and a one-line @return. Standard code-doc structure, no filler sentences, though the @-tag formatting is slightly verbose for an agent-facing description.

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?

For a 7-parameter write tool with no annotations, the description covers the operation, the gating precondition, all option defaults, and the return type; the output schema handles return structure. The only substantive omission is idempotency/error behavior on redeclaration, which keeps it below a 5.

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?

Schema description coverage is 0%, so the description must compensate, and it largely does: it documents all seven parameters, gives the allowed exchange type values (direct, fanout, topic, headers), and states defaults for type, durable, auto_delete, internal, and connection. It adds little detail on the 'arguments' extension map, which is the one remaining gap.

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?

States a specific verb and resource ('受控声明交换机' / declare exchange) plus scope ('在 Broker 中受控'), which is clear and distinct from siblings like rabbitmq_delete_exchange or rabbitmq_declare_queue. It stops short of naming which sibling to use instead, but the verb+resource pairing is unambiguous.

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 line about being bound by the global write-protection gate (--allow-write) is a real precondition an agent must satisfy. However, there is no statement of when to declare vs. reuse, no alternatives named, and no guidance on what to do if the exchange already exists.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the --allow-write write gate and names the return value, but omits other mutation-critical behavior: whether declaring an existing queue is idempotent, what happens on conflict, and required permissions.

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?

Purpose is front-loaded, followed by the write-gate constraint and then a structured parameter list. The @param enumeration is somewhat verbose, but for a six-parameter tool with no schema descriptions it earns its place.

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?

An output schema exists, so return values need not be explained. Combined with the write-gate disclosure and full parameter documentation, the definition is nearly complete for a mutation tool; the remaining gap is conflict/idempotency behavior on redeclaration.

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?

Schema description coverage is 0%, so the description must compensate, and it largely does: all six parameters are documented via @param tags with defaults and concrete examples for arguments (x-dead-letter-exchange, x-message-ttl). This is strong compensation, though it does not explain value constraints or formats beyond defaults.

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 states a specific verb (declare/声明) and resource (queue/队列), and highlights advanced capabilities like dead-letter routing and TTL. It is clearly distinguishable from siblings such as rabbitmq_delete_queue and rabbitmq_declare_exchange, though it never names them explicitly.

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 notes the operation is gated by the global write-protection flag (--allow-write), which is a useful precondition. However, it gives no explicit when-to-use vs when-not guidance or contrast with alternatives like rabbitmq_declare_exchange or rabbitmq_bind_queue; usage is only implied by the verb.

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

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

With no annotations provided, the description carries the full behavioral burden and does disclose a key safety mechanism: deletion requires secondary confirmation and otherwise yields a dry-run impact estimate. It still omits irreversibility, permission requirements, and what happens to bindings/messages, so it stops short of full disclosure.

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?

Content is front-loaded with the critical confirmation constraint before the parameter block, and the @param/@return structure makes it scannable. The @return line is marginally redundant given the output schema exists, but overall it is tight.

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 an output schema exists, return values need less prose, and the description still covers all four parameters plus the safety gate. It is complete enough to call correctly, with only permission/irreversibility context missing for a destructive operation.

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?

Schema description coverage is 0%, so the @param documentation does the compensating work: confirm and if_unused are given real semantics and defaults, and connection explains the 'default' alias choice. The name parameter is only restated minimally, so it is thorough but not exhaustive.

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?

States a specific verb (delete) and resource (exchange), with the qualifying scope '受控' (controlled) that signals the confirmation gate. It is clearly distinguishable from siblings like rabbitmq_declare_exchange and rabbitmq_list_exchanges.

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 explains the two-phase confirm workflow (unconfirmed calls only return an impact report per ADR-0002), which is implicit usage guidance. However, it never names an alternative tool or states when-not-to-use versus peers like rabbitmq_purge_queue or rabbitmq_delete_queue, leaving routing to inference.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the mandatory two-phase confirmation, that confirm defaults to False, that unconfirmed calls return only an impact-estimate report, and cites ADR-0002. It omits permissions required and irreversibility of the delete, so it is strong but not exhaustive.

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?

Front-loads the core behavior and the confirmation constraint, then uses compact @param/@return blocks. No sentence is wasted and the structured format is easy to scan.

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?

For a destructive mutation tool with no annotations and 0% schema description coverage, the description covers the confirmation flow, defaults, and all params, and an output schema exists so return formatting need not be spelled out. It could still mention required permissions or irreversibility, but it is substantially complete.

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?

Schema description coverage is 0%, so the description must compensate, and it documents all five parameters (name, confirm, if_unused, if_empty, connection) via @param tags. The explanations are terse but sufficient to understand each parameter's effect beyond the bare schema.

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?

States a specific verb+resource ('受控删除指定队列' – controlled deletion of the specified queue), which clearly distinguishes it from siblings like rabbitmq_purge_queue or rabbitmq_delete_exchange. It does not explicitly name an alternative, so it falls just 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.

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

The description implies when to use it via the mandatory confirmation workflow, but it never contrasts this tool with the alternative rabbitmq_purge_queue (which empties a queue without deleting it). Usage is implied 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.

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

With no annotations, the description carries the full burden and does well: it discloses that the default is non-destructive sampling, that ack=True physically removes messages, and that this destructive path is gated by the --allow-write write-protection to prevent accidental in-flight data loss. It omits any note on permission/connection requirements or what happens on missing queues, keeping it short of a 5.

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?

Front-loads the most important behavioral fact (default non-destructive sampling) before the parameter list, then uses a conventional @param block. Efficient and well-ordered, with only mild redundancy in restating schema defaults.

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?

An output schema exists so return values need no explanation, all four parameters are documented, and the destructive-mode risk is disclosed. The one real gap is the absence of any routing guidance relative to 'rabbitmq_peek_messages', which is the most likely confusion point for an agent.

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?

Schema description coverage is 0%, so the description must compensate, and it documents all four parameters (queue, count, ack, connection). Notably it adds the '1-50' range for count that the schema lacks (schema has only a default), though the default values it restates are already visible in the schema.

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?

States a specific verb and resource ('controlled pull of queue messages') and clearly contrasts its two modes (ack=False sampling vs ack=True physical dequeue). It does not, however, differentiate itself from the very similar sibling 'rabbitmq_peek_messages', which an agent could easily confuse it with.

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 each mode applies (sampling by default; ack=True only when you intend to remove messages) and flags the --allow-write gate for the destructive path. But it never names the alternative tool ('rabbitmq_peek_messages') or states when to prefer one over the other, leaving the key sibling choice to inference.

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

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 usefully discloses that the return contains deep metadata including dlx, TTL, and consumer details, but says nothing about read-only safety, required permissions, or behavior when the queue does not exist.

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?

It is compact and front-loaded: the purpose sentence comes first, followed by the parameter annotations. The @return line is slightly redundant given an output schema exists, but overall it is efficient.

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?

For a simple single-resource read with an existing output schema, the definition covers purpose and all parameters. The only real gap is the absence of any safety/error context, which is minor for a clearly read-only lookup.

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?

Schema description coverage is 0%, so the description must compensate, and it does: it documents all three parameters (@param queue, connection default 'default', vhost default '/'), giving each a meaningful role. This meaningfully fills the gap left by the undocumented schema.

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 states a specific verb (获取/get) and resource (指定队列/specified queue), and adds concrete scope by naming the metadata it returns (dlx, TTL policy, consumer details). This clearly distinguishes it from the list-oriented sibling rabbitmq_list_queues, though it never names that sibling explicitly.

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?

Usage is only implied: the emphasis on '指定队列' (a specific queue) suggests it is for inspecting a single known queue rather than enumerating. There is no explicit when-to-use/when-not or pointer to rabbitmq_list_queues vs rabbitmq_get_messages/peek_messages, leaving the agent to infer the routing.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it is thin: it never states that this is a safe read-only operation, whether it requires broker permissions or auth on the named connection, or how the '降级提示' (degradation hint) fallback triggers. The @return line is the only behavioral signal, and it is vague.

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?

Purpose is front-loaded in the first line and the @param/@return block is scannable with zero filler. The @return sentence is mildly redundant given an output schema exists, but the overall structure is efficient and well organized.

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?

For a read-only listing tool with an output schema, the definition covers the parameters adequately, and the output schema handles return values. It is still incomplete on the behavioral side: no annotations, no permission/auth context, no sibling differentiation, and no explanation of the degradation fallback it advertises.

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?

Schema description coverage is 0%, so the description is the only documentation source, and it does document all four parameters – connection (alias, default 'default'), and vhost/queue/exchange as optional filters. That adds real filtering semantics beyond the bare schema titles, though it stops short of giving filter syntax or precedence when multiple filters are combined.

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 states a specific verb (查询/query) and resource (交换机与队列之间的绑定映射规则 – exchange-to-queue binding mapping rules), which is concrete and distinguishable from the plain list_exchanges/list_queues siblings. It does not, however, explicitly distinguish itself from rabbitmq_bind_queue or rabbitmq_unbind_queue, which operate on the same resource and could be confused with it.

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?

There is no when-to-use or when-not-to-use statement and no reference to any sibling. The @param notes imply that vhost/queue/exchange are filters, but this is parameter semantics, not routing guidance – nothing tells the agent to call this rather than rabbitmq_bind_queue or rabbitmq_list_exchanges.

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

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

No annotations, so the description carries the full burden. It usefully discloses a behavioral trait — graceful degradation when the Management API is unconfigured (ADR-0001) — which the schema cannot convey. However, it omits auth/permission requirements, pagination, and any rate-limit behavior, leaving real gaps for a read tool with zero annotation coverage.

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?

Well front-loaded: purpose, then diagnostic use, then degradation note, then @param/@return tags. The structure is clean and each block earns its place, though the @param tags restate schema-level facts without much added depth.

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?

An output schema exists, so return detail needn't be explained, and the description focuses correctly on purpose, use case, degradation behavior, and parameters. It is nearly complete for a read-only channel listing tool; only auth and filtering-interaction details are missing.

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?

Schema description coverage is 0%, so the description must compensate, and it does: connection (alias, defaults to 'default'), vhost (optional filter), and connection_name (optional filter) are all documented with meaning. It does not clarify format/syntax of the alias or how the filters combine, keeping it from a 5.

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?

States a specific verb+resource (查询活跃信道指标 – query active channel metrics) and enumerates the concrete data surfaced: unacked message backlog, prefetch, and consumer activity. This clearly separates it from siblings like list_connections/list_queues via the 'channel' resource, but it never names the alternatives, so it stops 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.

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

Explicitly frames the use case: 用于精准排查客户端信道未确认消息积压、消费阻塞与信道异常 (for diagnosing unacked backlogs, consumption blocking, channel anomalies). That is clear when-to-use context, but there are no stated when-not conditions or comparisons to sibling tools.

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

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

No annotations are present, so the description carries the full burden. It usefully discloses the Management-API-absent fallback (graceful degradation per ADR-0001) and the diagnostic scope, but says nothing about permissions, rate limits, or what the degradation actually returns.

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?

Front-loaded purpose sentence, then routing note, then fallback note, then param tags. Slightly redundant with @param/@return duplicating schema and output-schema information, but nothing is padding.

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?

For a two-param, no-required-inputs read tool with an output schema, the description covers purpose, routing, fallback, and both params. Permissions and rate-limit context are the only meaningful omissions.

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?

Schema description coverage is 0%, so the description must compensate, and it does: it documents both parameters, including the alias default ('default') and the optional vhost filter semantics. No format examples are given, keeping it short of a 5.

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?

States a specific verb and resource in the first sentence (query external microservice client TCP connections, channels, throughput) and explicitly separates this tool from rabbitmq_list_connections and rabbitmq_list_configured_brokers. An agent can select it without opening the schema.

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 '[注意区分]' block gives an explicit when-to-use condition (diagnosing external app TCP links / channel leaks) and names the alternative tools for the other case. The stated split is a little confusing since rabbitmq_list_connections sounds like a sibling connection lister, but a routing decision is clearly provided.

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

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 discloses that the returned addresses are '脱敏' (desensitized/masked), which is useful data-handling context, and the verb '列出' (list) implies a read-only operation. However, it does not explicitly confirm read-only behavior, permissions required, or other operational traits such as pagination or rate limits.

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 front-loaded with the core purpose in the first sentence, followed by a clarifying sentence about its relationship to rabbitmq_list_connections, and ends with a brief @return note. Every sentence contributes useful information, and there is no redundant or wasted text.

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 tool's simplicity (no parameters, output schema present, no annotations), the description is largely complete: it states what is listed, what the addresses look like (desensitized), and how it differs from a sibling. The only minor gap is the absence of explicit read-only or permission information, though the list verb and output schema mitigate this.

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?

The tool takes zero parameters, and the schema description coverage is effectively 100% given the empty input schema. The description adds no parameter information because there are no parameters to describe, which matches the baseline of 4 for parameterless tools.

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 states a specific verb and resource: '列出...所有 RabbitMQ 目标 Broker 实例清单与脱敏地址' (list all configured RabbitMQ target broker instances and masked addresses). It explicitly distinguishes this tool from the sibling rabbitmq_list_connections by contrasting 'Broker 实例配置' (broker instance configuration) with '外部客户端 TCP 链路' (external client TCP connections). This gives an agent enough information to identify the tool's purpose without opening the schema.

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 names the alternative tool (rabbitmq_list_connections) and explains the context in which this tool is useful: to clearly distinguish broker instance configuration from external client TCP connections. It does not explicitly state when not to use it, but the distinction provides clear usage context. No misleading guidance is present.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: this is a read/list operation over configuration, and addresses are returned masked (脱敏), which the schema does not convey. It omits any auth/permission requirements or empty-config behavior, but for a zero-parameter read tool the disclosure is reasonably strong.

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?

Purpose is front-loaded in the first sentence, and the bracketed distinction note earns its space by preventing a wrong-tool call. The @return line is slightly redundant given an output schema exists, but overall it is tight and well-ordered.

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?

For a read-only, zero-parameter listing tool with an output schema present, the description covers scope, masking, and tool selection adequately; return-value detail is rightly left to the schema. The one gap is the unaddressed overlap with rabbitmq_list_configured_brokers.

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?

The tool takes no parameters, so per the rubric the baseline is 4. There is nothing for the description to add or omit on this dimension.

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?

It gives a specific verb+resource (list all RabbitMQ instance connections configured for this MCP service) and clarifies what the returned entity actually is — config-center Broker aliases, not live sockets. That is a real disambiguation. However, it never distinguishes itself from the very similarly named sibling rabbitmq_list_configured_brokers, which an agent could easily confuse with this tool.

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?

It explicitly routes the agent: use this for config-center managed Broker instances, use rabbitmq_list_client_connections to troubleshoot physical client TCP links. That is a clear when-to-use plus a named alternative. It stops short of covering the near-duplicate sibling rabbitmq_list_configured_brokers, leaving one routing hazard unresolved.

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

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 adds one genuinely useful trait — an output that may be a '降级提示' (degraded hint) rather than a full report — but omits auth requirements, connection failure behavior, and explicit read-only confirmation beyond the implied 'list'.

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 purpose sentence is front-loaded and the @param/@return tags are functional rather than redundant, since the schema carries no descriptions. The tag block is slightly boilerplate-heavy but every line conveys information not present elsewhere.

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?

An output schema exists, so return values need not be fully explained, and the @return line gives an adequate summary. For a low-risk read tool with zero annotation coverage, the description covers purpose and both parameters well; only usage routing against siblings is missing.

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?

Schema coverage is 0%, so the description must compensate, and it largely does: it labels the connection alias with its default and identifies vhost as an optional filter, documenting both parameters. It stops short of format examples for vhost or what a non-default connection alias must reference.

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?

States a specific verb+resource (查询...交换机列表) and adds scope detail (type and persistence config returned). This clearly separates it from write-oriented siblings like rabbitmq_declare_exchange and rabbitmq_delete_exchange, though it does not name any sibling explicitly.

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?

There is no when-to-use guidance at all — nothing says when to reach for list_exchanges versus list_queues or list_bindings, or under what conditions vhost filtering is desirable. It only documents parameters, leaving the selection decision entirely to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It adds useful detail about the returned metrics and the possibility of a 'degraded hint' response, but it does not disclose permissions, read-only nature, rate limits, or pagination behavior.

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 compact and front-loads the core purpose before the parameter annotations. Every line earns its place, though the @param/@return block is slightly repetitive of schema defaults.

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?

An output schema exists, so return values need not be fully explained, and the description covers both parameters. However, it falls short on sibling differentiation and behavioral safety details, which matter for an agent choosing between this and rabbitmq_get_queue.

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?

Schema description coverage is 0%, but the description compensates by documenting both parameters: the connection alias with its default, and the optional vhost filter. It adds meaning beyond the bare schema, though it does not explain parameter formats or edge cases.

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 first sentence names a specific verb (查询/list), the resource (全部队列/all queues), and the returned metrics (积压消息、未确认数、消费者全景指标). It is clear what the tool does, but it does not explicitly distinguish itself from the sibling rabbitmq_get_queue, which is also queue-focused.

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 that this tool is for listing queues, but it gives no explicit when-to-use guidance, no exclusions, and no mention of the sibling rabbitmq_get_queue or other alternatives. An agent must infer the context entirely.

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

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

With no annotations, the description carries the full burden, but it does disclose a genuine behavioral trait: graceful degradation when the Management API is absent, plus the ADR-0001 dual-core architecture context. It does not clarify read-only safety, permissions, or whether the fallback yields partial data, so it is useful 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.

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

The purpose is front-loaded in the first line, followed by the degradation caveat and param/return tags. Reasonably tight, though the ADR-0001 architecture reference is internal jargon that adds little for an invoking agent.

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?

An output schema exists, so return values need not be explained, and the single optional parameter is covered. What is missing is usage context — when to call this instead of the many granular rabbitmq_* siblings — leaving the agent to infer the routing.

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?

Schema description coverage is 0% for the single 'connection' parameter, but the description compensates by defining it as the target connection alias with a 'default' value. That explains the parameter's meaning; the default itself is already in the schema, so the added value is modest.

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 states a specific resource and scope ('cluster node status, queue statistics, and global message throughput dashboard'), which clearly separates it from the list/get siblings like rabbitmq_list_queues or rabbitmq_get_queue. It doesn't explicitly name those siblings, but the cluster-wide aggregation framing is distinct enough for an agent to route correctly.

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?

There is no guidance on when to prefer this overview over the granular sibling tools, nor any prerequisites. The only conditional statement ('automatically degrades when Management API is not configured') is a runtime behavior, not a usage recommendation.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the reject(requeue=True) mechanism, zero data loss, no dequeue, and no duplicate reads (ADR-0002). This is exactly the behavior an agent needs before touching broker messages. Gaps remain on permissions/rate limits and 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.

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

Front-loaded with purpose and safety implication, followed by a compact mechanism sentence and three @param lines. The mechanism sentence is slightly dense but each clause earns its place for a tool where data loss is a real risk.

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?

For a 3-parameter read tool with an output schema (so return values need not be described), the definition covers purpose, safety mechanism, and parameter meanings. Missing only explicit routing against the sibling get/consume tool.

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?

Schema description coverage is 0%, so the description must compensate, and it does: it explains 'queue' as the target queue name, 'count' as a sampling limit with range 1-50 (default 10), and 'connection' as a target alias defaulting to 'default'. The range constraint and defaults are meaningful additions beyond the bare schema titles.

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?

States a specific verb+resource: non-destructive sampling (peek) of queue-head messages, with the key qualifier '无损' and '不出队' that separates it from a consuming read. It does not explicitly name the sibling rabbitmq_get_messages, so the differentiation is inferred rather than stated.

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?

'诊断采样' implies a diagnostic/inspection use case, but there is no explicit when-to-use or when-not guidance and no alternative named (e.g., why peek instead of rabbitmq_get_messages). Usage must be inferred from the purpose.

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

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

No annotations, but the description carries behavioral weight: it explains that a low-level TCP/AMQP session and channel are established then immediately closed safely, and that a structured report is returned. Missing auth/permission details keeps it from 5.

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?

Short, front-loaded, and uses @param/@return tags efficiently. Every sentence earns its place.

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?

With an output schema present, the description need not explain return fields, and it already covers purpose, safety behavior, and the lone parameter. Complete for a simple ping tool.

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?

Schema coverage is 0%, so the description must compensate; it does by explaining that 'connection' is a target connection alias and defaults to 'default'. It does not add validation, format, or source-of-alias detail.

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?

States a specific verb+resource: measuring AMQP round-trip latency to RabbitMQ, with a clear health-probe framing. It implies a distinct role from list/declare/delete siblings, even without naming one.

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?

Indicates the use case (network reachability and response-time probing), which gives clear context for when to use it. It does not name alternatives or when-not conditions, so it stops short of 5.

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

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: the write gate requirement, automatic JSON serialization, persistence via delivery_mode, and a delivery-confirmation return. It stops short of failure semantics or whether the exchange must pre-exist.

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?

Purpose is front-loaded in the first sentence, followed by the gate warning and a compact @param block. The @param repetition is justified because the schema carries zero descriptions, so little is wasted.

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?

For an 8-parameter write tool with no annotations but an output schema, the description documents every parameter and the write gate, leaving return values to the output schema. Minor behavioral gaps (error handling, exchange existence) remain but are not blocking.

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?

Schema coverage is 0%, so the description must compensate, and it does: it defines delivery_mode (1=non-persistent, 2=persistent), priority range (0-255), expiration units (ms as number or string), payload types (dict/list/str/bytes), and defaults for routing_key and connection. This goes well beyond what the bare schema conveys.

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?

States a specific verb+resource ('publish a message') with the addressing target (exchange + routing key), which cleanly separates it from the declare/bind/list siblings. An agent can identify this as the message-sending tool without opening the schema.

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 notes it is gated by the global write-protection flag (--allow-write), which is a genuine usage prerequisite, but it never states when to prefer this over alternatives or any when-not conditions. Usage is only implied by the tool's name.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that this is a destructive purge of all pending messages, that a second confirmation is mandatory, and that an unconfirmed call safely degrades to an impact estimate (ADR-0002). It omits permission requirements and irreversibility guarantees, but the confirmation/dry-run behavior is genuinely useful context beyond the schema.

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?

Front-loaded with the purpose and the safety constraint, followed by compact JSDoc tags. The tag block is slightly redundant with the opening prose but earns its place by documenting otherwise-undocumented parameters.

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?

An output schema exists, so return values need not be detailed here, yet the @return line still summarizes the two possible outcomes. For a destructive queue operation with zero annotations, the definition covers the operation, the safety workflow, and all parameters adequately.

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?

Schema description coverage is 0%, so the description must compensate, and it documents all three parameters via @param tags, including the semantics and defaults of 'confirm' (False) and 'connection' ('default'). It adds meaningful meaning over a bare schema, though it does not clarify connection-alias resolution or name format.

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?

States a specific verb and resource ('清空/purge' the '指定队列') plus the exact scope ('全部待消费消息'), which cleanly separates it from rabbitmq_delete_queue (removes the queue) and rabbitmq_get/peek_messages (reads messages). An agent can identify the operation without opening the schema.

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 explains the two-step confirm workflow but never states when to prefer this over siblings such as rabbitmq_delete_queue, nor any prerequisites beyond the confirm flag. Usage is implied by the destructive-purge semantics rather than explicitly guided.

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

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

With no annotations provided, the description must carry behavioral disclosure. It does disclose the write-protection gate that can block the call, which is genuinely useful context, but it omits reversibility (re-bind), error behavior when the binding does not exist, and any auth/scope details beyond the gate.

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?

One sentence of purpose front-loaded first, followed by a compact @param block and a @return line. Every line maps to a real field or behavior and there is no filler.

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?

An output schema exists, so the terse @return note is sufficient and return values need not be expanded. For a 5-parameter mutation with zero schema coverage, the description covers purpose, all parameters, defaults, and the write gate; the only meaningful gap is not routing the agent to bind_queue or explaining failure modes.

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?

Schema description coverage is 0%, so the description carries the full burden, and it delivers: every one of the 5 parameters gets a meaning plus defaults for routing_key ('') and connection ('default'). No format, alias-list, or argument-shape detail is added, but the semantic mapping is complete.

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 states a specific verb and resource: '解除队列与指定交换机之间的路由绑定' (remove the routing binding between a queue and a specified exchange). This clearly distinguishes it from the sibling rabbitmq_bind_queue by operation direction, though it never names that sibling explicitly.

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?

It discloses a real gating condition — the tool is subject to the global write-protection gate (--allow-write) — which tells the agent when the call will be blocked. However, there is no explicit guidance on when to choose unbind over bind, or on prerequisites such as the binding existing first.

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