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

Annotations declare readOnlyHint=true and the description's '[READ]' tag is consistent, so no contradiction. Beyond that the description adds real behavioral context: per-platform analysis logic, grouping 'by source so a finding can be pinned to an app', and the stateful snapshot/history delta pattern. It omits auth/config prerequisites and any rate or size 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 read-mode tag and flagship statement are front-loaded, and the per-platform detail is dense but earns its place. The phrase 'The flagship churn analysis' is mild filler and the arrow/smell shorthand assumes familiarity, but overall the content 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?

With no output schema, the description compensates by spelling out the Returns dict ({platform, metrics, bySource, comparedToHistory, thresholds, findings, note}) and the delta workflow. Gaps remain around the precedence of snapshot vs target when both are supplied and what thresholds/note contain, but an agent has enough to call it correctly.

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 carry the load, and it does document all three params: snapshot ('skips the live pull'), history ('prior snapshot for delta analysis'), target ('Broker target name from config; omit for the default'). The exact internal shape of the snapshot/history objects remains vague, but the Returns block hints at it.

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 opens with a specific verb+resource ('[READ] Connection/channel churn → cause + action') and then enumerates exactly what it computes per platform: redis reconnect-per-operation and maxclients rejection smells, rabbitmq overview churn, channels-per-connection leak smell. It is very precise about scope, though it never names which sibling (e.g. redis_latency_rca vs redis_memory_pressure_rca) it should be chosen over.

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 gives clear operational context: 'Call it once, keep the returned snapshot fields, and pass them back later as history for delta-based churn' and 'Pass snapshot for pure analysis, or a target to pull live.' This tells the agent how to sequence calls and which argument selects which mode. It stops short of stating when NOT to use it or pointing to an alternative diagnostic tool.

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?

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=false, but the description adds real behavioral detail: the undo only deletes the queue if it was newly created, whether pre-existence is recorded, and that dry_run previews the effect. It still doesn't say what happens when a queue exists with conflicting arguments or what permissions are required.

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 [WRITE][risk=medium] marker and the core action, followed by behavioral notes and an Args block where every line earns its place. Slightly dense, but nothing is 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?

For a mutating, undo-aware tool with no output schema, it covers creation, undo semantics, preview mode, and per-parameter meaning. The remaining gap is error/precondition behavior (queue already exists with different args) and permission requirements.

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 carry the load, and it documents all seven parameters with defaults (vhost default '/', durable True, auto_delete False), semantics, and an example value for arguments ('x-queue-type': 'quorum'). This fully compensates for the empty 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 and resource ('Declare (create) a rabbitmq queue') plus risk level, and the undo/replay-target sentences distinguish it from siblings like delete_queue, purge_queue and list_queues. An agent can route here without opening any 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?

Gives clear operational context: it is a write, dry_run=True previews, and it is the replay target for delete_queue's undo. It does not state exclusions (e.g., use list_queues/queue_detail to inspect rather than declare), so it stops short of full when/when-not guidance.

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?

Annotations already declare destructiveHint=true, so safety is covered; the description adds genuinely new behavior — it reads the policy first so the recorded undo can re-create it exactly, and supports a dry-run preview. It omits failure modes (nonexistent policy, permissions, effect on bound queues).

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 two most decision-relevant facts ([WRITE][risk=medium] and undo-recreates-it) before the parameter list. The Args block is terse and every line adds meaning rather than restating types.

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 no output schema, the description is responsible for the return contract and it covers the important part (undo re-creation). It stops short of describing error behavior or post-delete state, which matters for a destructive mutation.

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% (titles only), so the description carries the load and does so: vhost default '/', name sourced from list_policies, dry_run as preview, target defaulting to config. 'target' is explained only loosely ('from config'), leaving mild ambiguity.

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 ('Delete a rabbitmq policy') and immediately distinguishes the operation by noting the undo re-creates it. Against siblings like set_policy, list_policies, and delete_queue, the resource 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?

Gives actionable context: 'Pass dry_run=True to preview' and tells the agent where to get the policy name ('from list_policies'). It does not, however, state when not to delete or how it relates to set_policy for modifying rather than removing a policy.

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?

Goes well beyond the annotations (destructiveHint/idempotentHint/readOnlyHint) by disclosing the exact undo contract: the queue is read first so priorState captures durable/auto_delete/arguments and message count, the undo re-declares the definition, and the messages are NOT restored. This is exactly the behavioral context an agent needs before an irreversible operation.

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 [WRITE][risk=high] marker and the one-line purpose are front-loaded, followed by the undo semantics and a compact Args list. It is slightly longer than strictly necessary, but every sentence carries operational value and nothing is redundant.

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 tool with no output schema and 0% schema coverage, the description covers what changes, what is recoverable (definition, not messages), how to preview, and all parameter inputs. An agent has everything needed to call it correctly and safely.

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 does so: vhost (with the '/' default), name (with the source, list_queues), dry_run (preview semantics), and target (config-derived, omit for default). Every one of the four parameters gains meaning not present in 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?

Names a specific verb and resource ("Delete a rabbitmq queue") plus a severity tag, so the agent knows exactly what it does. It hints at differentiation from purge_queue by noting messages are NOT restored, but never names that sibling explicitly, so it falls short of the top tier.

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?

Gives a preview path (dry_run=True) and describes the undo model, which implies when the tool is appropriate. However there is no explicit when-to-use guidance nor a named alternative for narrower operations such as purge_queue or declare_queue, so routing is left 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?

Annotations only declare readOnlyHint=true, so the description usefully adds the sort order and, importantly, the truncation contract ('when truncated is true there is more than was returned'). No output schema exists, so surfacing the envelope shape and the truncation warning is genuinely valuable behavioral context.

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 '[READ]' tag, then a compact Args block, then the return envelope. Every sentence earns its place; the only minor cost is the somewhat formal multi-section layout for a one-parameter tool.

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 single-parameter read-only tool with no output schema, the description covers the key unknowns: parameter semantics, sort order, envelope shape, and truncation semantics. It omits per-channel field details, but nothing blocks correct invocation.

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 carry the burden, and it does: 'target' is explained as a RabbitMQ target name from config, optional, defaulting when omitted. It could be more specific about valid target sources, but it covers optionality and meaning well.

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 (list), resource (channels), and scope (those with unacked/prefetch pressure), plus an ordering rule (most unacked first). This distinguishes it clearly from sibling list tools like list_queues and list_connections.

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 pressure-focused framing implies a troubleshooting scenario, but the description never states when to prefer this over list_queues, list_connections, or the rabbitmq_queue_backlog_rca sibling, nor any exclusions or prerequisites.

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?

Annotations only declare readOnlyHint=true, so the description carries real added weight: it discloses the grouping/ordering behavior and, critically, the return envelope with a 'truncated' flag plus an explicit warning not to treat a truncated result as complete. That is decision-relevant behavior an agent could not derive from 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.

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

Front-loaded with the core purpose, then cleanly split into Args and Returns sections with no filler. Slightly more boilerplate than strictly necessary, but every sentence carries information.

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 no output schema, the description helpfully documents the response envelope and truncation semantics, which covers the main gap. One minor loose end: the envelope reports a 'limit' field but the tool exposes no way to set that limit, so the agent cannot tell whether truncation is controllable.

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 for the single 'target' parameter, and it does: it explains the value comes from config and that omitting it selects the default. Full meaning is conveyed, though no example values are given.

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 ('Client connections') and adds meaningful scope detail ('grouped by peer host, busiest first') plus a [READ] marker. It is clearly distinguishable from resource-different siblings like list_queues or list_channels, but it never explicitly contrasts itself with the closest sibling, connection_churn_analysis.

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 resource name and the [READ] tag, and the Args note tells the agent how to pick a target, but there is no explicit statement of when to call this versus alternatives such as connection_churn_analysis.

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?

readOnlyHint=true already declares the safety profile, but the description goes further by documenting the return envelope shape and, critically, the 'truncated' flag semantics ('do not treat this as the complete set'). That truncation warning is genuinely useful context beyond annotations.

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

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

Front-loads purpose, then Args, then Returns — a clean structure where each block earns its place. Slightly verbose in the returns section but no wasted sentences.

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 list tool with two optional params and no output schema, the description covers both parameters and the response envelope including pagination/truncation behavior. Nothing an agent needs to call it correctly 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 carry the load — and it does, clarifying that vhost defaults to '/' and that target is a 'rabbitmq target name from config' omitted for the default. This is meaningful semantics the bare schema lacks.

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 ('Policies') and enumerates the returned fields (pattern, priority, definition), with a '[READ]' marker that separates it from set_policy/delete_policy by implication. It never explicitly names a sibling, so it falls just short of full 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?

The Args section implies usage context ('omit for all', 'omit for the default'), giving basic guidance on scope selection. However, it never tells the agent when to choose this over sibling tools like list_queues or set_policy, so usage is only implied.

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?

Annotations cover only readOnlyHint, but the description adds genuinely useful behavior: result ordering by backlog depth, the envelope's returned/limit/truncated fields, and the explicit warning not to treat a truncated result as complete. That truncation caveat is exactly the kind of context an agent needs and cannot get from 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?

Front-loaded scope statement followed by clearly labeled Args and Returns sections; every sentence carries information. The '[READ]' prefix is slightly redundant with readOnlyHint=true, but the structure is tight and skimmable.

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 no output schema, the description correctly compensates by documenting the return envelope and the truncated flag. The remaining gap is that the shape of individual queue objects inside 'queues' is never described, so the agent knows the wrapper but not the payload.

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% — the schema exposes only nullable strings with no titles or descriptions — so the description carries the full burden and does so: it defines vhost (default is '/', omit for all) and target (a rabbitmq target name from config, omit for default). Both parameters' omit-semantics are spelled out, which is well beyond 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 the resource (queues), the optional scope (one vhost or all), and a specific ordering rule ('deepest backlog first'), which is a meaningful discriminator for triage work. It does not explicitly name how it differs from close siblings like queue_overview, queue_detail, or rabbitmq_queue_backlog_rca, 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?

The description explains argument usage ('omit for all', 'omit for the default') but gives no guidance on when to pick this tool over sibling listing/detail tools (queue_overview, queue_detail, rabbitmq_queue_backlog_rca). Usage is implied by the READ tag and the sort order rather than 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?

readOnlyHint=true already declares the safety profile, and the description reinforces it with the [READ] tag. It adds useful output-shaping context (watermark alarms, most-loaded-first ordering) but says nothing about auth, rate limits, or how the posture is aggregated across nodes.

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 front-loaded sentence for purpose plus one line for the argument; no filler or repetition. The [READ] tag and ordering caveat are placed where a scanning agent will see them first.

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, single-optional-param tool with no output schema, the description covers what the tool reports and how results are ordered, which is most of what an agent needs. It could say more about per-node granularity or whether it covers a cluster, but nothing essential 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% and the schema entry for target is bare, so the description carries the load: it explains target is a RabbitMQ target name sourced from config and that omitting it uses the default. That resolves the parameter's origin and default behavior, which the schema does not.

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?

Names a specific resource and scope: node memory/disk/fd posture plus watermark alarms, with the [READ] tag signalling the operation class. It is clear what an agent gets back, though it doesn't explicitly contrast with siblings like rabbitmq_overview or queue_overview that could superficially sound similar.

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 and no alternative named. The only routing-like information is the ordering hint 'most loaded first', which helps interpret results but does not tell an agent under what conditions this tool is preferable to rabbitmq_overview or the RCA 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?

Goes well past the destructiveHint/readOnlyHint annotations: irreversibility, no undo, the exact scope of destruction (ready but not unacked messages), the pre-read that populates priorState with the destroyed count, and a dry-run escape hatch. This is the kind of detail an agent needs before firing a high-risk write.

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 risk tag and the core action, then a structured Args block. Slight redundancy between 'IRREVERSIBLE' and 'No undo — purged messages cannot be restored', but every paragraph still 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?

No output schema exists and none is needed: the description explains that priorState returns the count about to be destroyed and clarifies what is and isn't affected. For a 4-param destructive tool, nothing required to invoke it safely 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?

With 0% schema description coverage, the Args block carries the full burden and does so for all four parameters: vhost with its '/' default, name with its provenance (list_queues), dry_run's preview semantics, and target as an optional config target name whose omission selects the default.

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 precise verb+resource+scope: 'Purge all ready messages from a rabbitmq queue', with the [WRITE][risk=high] tag and 'IRREVERSIBLE' immediately signalling the operation class. This cleanly separates it from siblings like delete_queue (removes the queue itself) and list_queues (read-only enumeration).

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?

Gives clear operative guidance: read the queue first for audit evidence, unacked messages are not purged, and pass dry_run=True to preview. It points to list_queues as the source of the queue name, but does not explicitly contrast with the delete_queue/declare_queue siblings or state when purging is the wrong choice.

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?

The '[READ]' prefix duplicates the readOnlyHint annotation rather than adding to it. The description does add value by enumerating the returned data categories and noting the default vhost ('/') and that target may be omitted, but it discloses nothing about permissions, rate limits, or behavior for a non-existent queue.

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 one-line purpose before the Args block, and every line contributes. Slightly over-formatted for a three-parameter read tool but nothing is wasteful.

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 no output schema, the description usefully names the return fields (counts, rates, consumers, memory, arguments), and all params are documented. Adequate for a read-only inspection tool, though it omits error/not-found behavior.

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 defines vhost (default '/'), name (sourced from list_queues), and target (rabbitmq config target, omit for default). All three parameters get useful semantics; only deeper syntax detail is missing.

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 resource and scope: 'One queue's full detail', enumerating the categories of data (counts, rates, consumers, memory, arguments). This implicitly separates it from list_queues (plural, list-level) and queue_overview, though it never names those siblings 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 name parameter is annotated '(from list_queues)', which hints at a list-then-inspect workflow. There is no explicit when-to-use guidance, no when-not-to-use, and no mention of alternative siblings such as queue_overview or rabbitmq_queue_backlog_rca.

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?

The readOnlyHint annotation confirms non-destructive behavior, and the description goes beyond it by spelling out that output is dispatched by platform type, listing the specific metrics each branch reports. That is genuinely additive context beyond the annotation, though it says nothing about cost, timeouts, or failure behavior when a target is unreachable.

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, followed by the platform-dispatched return shape, then the argument. Three compact blocks with no filler sentences; every clause adds selection or invocation value.

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 no output schema, the description usefully sketches the return surface per broker, and the read-only annotation covers the safety profile. A small gap remains around error/unavailable-target behavior, but an agent has enough to call it correctly.

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% for the single parameter, so the description must carry the burden, and it does: 'target: Broker target name from config; omit for the default' explains both origin and defaulting behavior. It stops short of naming valid targets or stating what happens for an unknown target.

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 ('one-shot summary') and enumerates exactly what is aggregated: platform, version, backlog/memory/client health, with per-broker breakdowns. It is distinguishable from detail-oriented siblings like queue_detail and list_queues, though it never names or contrasts with rabbitmq_overview, which overlaps heavily for the rabbitmq branch.

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 only routing guidance is 'omit for the default,' which explains the parameter default rather than when to choose this tool over alternatives. Usage as the top-level summary entry point is implied by 'one-shot summary' but there is no explicit when-to-use or when-not-to-use statement versus node_health, rabbitmq_overview, or the RCA 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?

The [READ] tag and readOnlyHint=true annotation jointly make clear this is a safe, non-mutating call, so the description's safety contribution is redundant rather than additive. It does not disclose auth requirements, result size/limits, or whether the broker-wide aggregation is expensive.

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?

Very tight: one summary line followed by a short args note, with the read-only marker and scope front-loaded. The bracket-tag style is terse but no sentence is wasted; the only cost is that terseness leaves room for more routing guidance.

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 a single optional parameter, no output schema, and readOnlyHint covering the safety profile, the description supplies what an agent needs to invoke it correctly and previews the returned categories (version, counts, rates, churn). Missing only the comparative context against sibling overview tools.

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 for the single 'target' parameter, and it does: it explains the parameter is a target name from config and that omitting it selects the default. That is exactly the missing semantic detail the schema lacks.

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 concrete verb+resource: reading broker identity and aggregate totals (version, queue/message counts, rates, churn). It is clear what the tool returns, but it does not explicitly position itself against near-neighbors like queue_overview or list_queues, so an agent must infer the granularity difference.

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 usage ('overview' = broad health snapshot) and clarifies the only argument behavior ('omit for the default'), but never states when to prefer this over queue_overview, list_queues, or connection_churn_analysis. No exclusions or prerequisites are given.

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?

Annotations only supply readOnlyHint=true, but the description goes well beyond that: it enumerates the classification causes (no consumers, unacked pileup, publish outpacing delivery, residual backlog), discloses global memory/disk watermark alarms that block publishers via flow control, and states that every finding carries its numbers. This is rich behavioral context about what the analysis actually detects.

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 one-line purpose and the flagship framing before the Args/Returns blocks, and every section earns its place. The explanatory paragraph is dense but informative rather than redundant; slight length is the only blemish.

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 no output schema, the description supplies the return shape itself ({queuesEvaluated, backloggedCount, globalFindings, queues:[...], thresholds, note}), covers all params, and describes the detection logic. An agent has everything needed to call and interpret the 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% and all five params are undocumented in the schema, so the description carries the full burden — and it does: vhost (restrict live pull, omit for all), top (row count, default 20, deepest first), queues and nodes (with the exact injected row field shapes), and target (config target, omit for default). This fully compensates for the coverage 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+resource ('Rank backlogged queues and map each to a cause + action') and immediately positions itself as the 'flagship backlog RCA', which distinguishes it from plain listing siblings like list_queues, queue_overview, and queue_detail. An agent can tell what it does and why it exists 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?

Explicitly defines the two invocation modes: 'Pass queues (and optionally nodes) for pure analysis, or a target to pull live', plus vhost scoping. It gives clear context for how to call the tool, but never names a sibling alternative (e.g. queue_detail) or states when NOT to use this RCA over them.

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?

Annotations only declare readOnlyHint, while the description adds critical behavioral detail: SCAN walks at most 10,000 keys, MEMORY USAGE sizes at most 200, coveragePct reports partiality, and truncated=true means the result is incomplete. This is rich, safety-relevant disclosure that goes well beyond the annotation.

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 key summary, then method and safety, then Args and Returns. Every sentence earns its place, and the return envelope is documented because no output schema exists. It is appropriately sized for a tool with non-obvious sampling behavior.

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 sampling complexity, 0% schema coverage, and no output schema, the description is complete: it explains the sampling budget, safety, both parameters, and the exact return envelope including the truncated warning. An agent has everything needed to call it correctly and interpret partial results.

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. It explains both parameters: 'top' controls how many key rows to return, largest first (default 20), and 'target' is a redis target name from config, omitted for the default. This covers the two optional parameters adequately, though it does not elaborate on target value formats or error behavior.

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: 'SCAN-budgeted big-key sample — largest sampled keys first.' It clearly distinguishes from generic keyspace tools by naming the big-key sampling goal and the safety mechanism (never KEYS *). An agent can identify this as the tool for finding large keys.

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 usage by explaining the sampling method and production safety, but does not explicitly say when to use this versus siblings like redis_keyspace or redis_memory_stats. It gives useful context about safety, yet no when-not or alternative routing is 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?

Annotations already declare readOnlyHint=true, but the description goes further by disclosing the return envelope and the meaning of 'truncated', explicitly warning that a truncated result is not the complete set. With no output schema present, this disclosure is genuinely additive; it does not, however, say how to obtain the remaining rows.

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 purpose in one bracketed line, then a compact Args block and the return contract. Every element earns its place, though the envelope explanation runs slightly long for a single-parameter read tool.

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 read-only tool with one parameter and no output schema, the description covers input semantics and the return shape including truncation, which is what an agent needs to interpret results. The missing piece is any indication of how to page past a truncated response.

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 carry the parameter, and it does: 'target: redis target name from config; omit for the default' explains both the source of valid values and the default behavior of the nullable parameter. That fully compensates for the empty schema description.

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 — connected Redis clients — plus the ordering ('grouped by source address, busiest first'), which lets an agent predict the shape of the result. It does not explicitly contrast itself with siblings like list_connections or redis_kill_client, so a 4 rather than 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 only guidance is how to supply 'target' ('omit for the default'), which is parameter help rather than usage routing. There is no statement of when to inspect clients versus using redis_kill_client, list_connections, or the RCA tools, and no prerequisites are named.

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?

The description's '[READ]' marker merely restates readOnlyHint=true from the annotations. It adds no behavioral context such as auth/permission requirements, whether sensitive values are masked, or what the response shape looks like, so it contributes little beyond the structured annotation.

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 and front-loaded — the operation and its example come first. The 'Args:' block is slightly redundant with the schema but stays compact with no wasted prose.

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-optional-parameter read of server config, the description is nearly sufficient. The remaining gap is the return format — with no output schema, the agent gets no hint that CONFIG GET returns name/value pairs for the matched glob.

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 carries the burden and does document both parameters: 'pattern' as a config-name glob with default '*', and 'target' as a redis target name from config with omission meaning the default. This adds real meaning over the bare schema titles, though no glob syntax or target-format examples are given.

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: 'CONFIG GET for a glob pattern', with a concrete example ('maxmemory*'). The '[READ]' tag signals it is the read-only counterpart to redis_config_set, 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 implied by the '[READ]' tag and the CONFIG GET semantics, but the description never says when to reach for this instead of redis_server_info, redis_config_set, or other inspection tools. It is adequate but leaves the routing to the agent.

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?

Annotations only give the coarse profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false); the description adds substantial context beyond that: it performs CONFIG GET first to record a restorable undo, changes are runtime-only and not persisted, the refusal set is enumerated with the reason (undo could never be replayed), and the refusal also applies under dry_run so a preview cannot falsely report a green 'wouldSet'. This is exactly the kind of hidden behavior the annotations cannot carry.

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 severity tags and the core action, then the durable/undo semantics, then the refusal list, then args. The enumerated refused-parameter list is long, but each entry is load-bearing safety information rather than 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?

With no output schema and only coarse annotations, the description still supplies everything needed to call this correctly: parameter provenance, dry-run preview behavior, undo/reversibility guarantees, persistence caveats, and the failure modes with their workaround. Nothing material is left for the agent to guess.

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% and all four parameters are titled generically (Value, Target, Dry Run, Parameter), so the description must compensate — and it does: it identifies parameter as a config name sourced from redis_config_get, explains target as a config-defined redis target with a default when omitted, and clarifies dry_run's exact semantics including its interaction with refusals. It only stops short of showing value syntax per parameter type.

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 ('Set one redis config parameter') with scope (single parameter) and pairs it with the sibling it depends on ('from redis_config_get'). An agent can distinguish it from redis_config_get and the other redis_* tools without opening any 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?

Gives explicit when-to-use (set one parameter, optionally via dry_run=True preview), when-not (the refused parameter list — use redis.conf and restart instead), and names the read counterpart redis_config_get as the source of valid parameter names. Alternatives and exclusions are spelled out rather than inferred.

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?

readOnlyHint=true already covers the safety profile, so the description's job is to add context. It does add the data source (INFO keyspace) and the default-target behavior, but says nothing about cost, freshness, or what happens when the target is unreachable.

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 front-loaded sentence plus a short args block; every line earns its place. The 'Args:' formatting is slightly mechanical but not wasteful.

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 single-parameter read tool with no output schema, the description names the return content (key counts and expiry coverage) and the parameter's semantics, which is enough to invoke correctly. Minor gaps around target naming and error behavior.

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% and the single parameter has no schema description, so the description carries the burden: it explains that target names a redis target from config and that omitting it selects the default. That is exactly the missing semantics, though it doesn't say what a valid target name looks like.

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 resource and scope: per-db key counts and expiry coverage sourced from the INFO keyspace section. This clearly distinguishes it from sibling redis_memory_stats or redis_config_get, though it does not explicitly note the overlap with the broader redis_server_info.

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 [READ] tag hints at read-only usage and the target arg note says when to omit it, but there is no guidance on when to reach for this tool instead of redis_server_info or redis_memory_stats, and no prerequisites 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?

Annotations only carry the generic safety profile (destructive, non-idempotent); the description goes well beyond by declaring irreversibility, that no undo entry is recorded, that priorState is captured from CLIENT LIST, and that most clients reconnect. The self-connection refusal rule, including its behavior under dry_run, is exactly the kind of edge case annotations cannot express.

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 leading [WRITE][risk=medium] tag and the IRREVERSIBLE warning are front-loaded, and the body is dense with decision-relevant facts rather than filler. The Args block partially restates the schema, but with 0% schema coverage that repetition is earned.

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 tool with no output schema and no annotation detail, the description covers irreversibility, prior-state capture, preview mode, and refusal semantics. It stops short of describing the shape of a successful response, but priorState is at least characterized.

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 carry all parameter meaning and it does: it defines client_id (preferred, sourced from redis_clients), addr as 'ip:port', dry_run, and target as a config name defaulting to the default target. It does not state that at least one of client_id/addr must be supplied, a minor gap given all four params are optional with 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?

States a specific verb+resource (disconnect one redis client) and the two accepted identifiers (id or addr). It is clearly distinguishable from the read-only sibling redis_clients and from unrelated queue/policy tools.

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?

Tells the agent how to preview (dry_run=True), points to redis_clients as the source of client_id, and documents the refusal case including under dry_run. It lacks explicit when-not-to-use guidance relative to siblings such as undo_apply or connection_churn_analysis, but the operating context is clear.

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?

Annotations only declare readOnlyHint=true, and the description goes well beyond that by naming the exact data sources it reads (SLOWLOG by command pattern, INFO stall signals like blocked clients, fork stalls, delayed AOF fsyncs, dataset loading). It even discloses that every finding carries its numbers. It doesn't mention rate limits or cost of the live pull, so not a full 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 one-line purpose and [READ] marker, then structures Args and Returns clearly with no filler. The paragraph enumerating stall signals is dense but each item earns its place as diagnostic content; total length is slightly long for a 3-param tool.

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?

No output schema exists, but the description summarizes the return dict structure (slowlogPatterns, patternsOverThreshold, thresholds, findings with cause/action/evidence, note), and with the readOnly annotation plus full arg docs an agent has everything needed to call and interpret this tool correctly.

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 schema coverage at 0%, the description carries the burden and does: it documents slow_us with its unit and default (10000 = 10ms), enumerates the telemetry object's keys and meaning, and explains target as 'a redis target name from config; omit for the default.' The only gap is the absence of types/units for the nested telemetry fields, but coverage is strong overall.

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 ('Diagnose redis latency') and enumerates exactly what it produces: slowlog digest by command pattern plus stall causes and actions. It is clearly distinguishable from siblings like redis_slowlog (raw slowlog) and redis_memory_pressure_rca (memory-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?

Gives explicit operational guidance: 'Pass telemetry for pure analysis, or a target to pull live,' which tells the agent both modes of invocation. It stops short of naming when to prefer this over redis_slowlog or the other RCA siblings, leaving that comparison 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?

Annotations only declare readOnlyHint=true; the description adds genuine behavioral context beyond that, decoding eviction policy ('noeviction near the limit means writes will OOM') and fragmentation (below 1 = likely swapping), and noting the big-key sample is SCAN-budgeted. It stops short of auth/permission or execution-cost 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?

Front-loads the purpose, then signals, then Args and Returns in labeled blocks, so scanning is easy. Slightly verbose in the opening paragraph but no sentence is pure 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?

No output schema exists, yet the description spells out the return dict keys (pressure, usedPctOfMax, maxmemoryPolicy, fragmentationRatio, evictedKeys, thresholds, findings, note), closing the gap. For a 3-param read-only diagnostic this is 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?

With 0% schema coverage the description must carry the parameter burden and largely does: used_pct default and meaning, target origin ('from config; omit for the default'), and the nested telemetry shape ({memory:{...memory_stats fields}, evictedKeys, bigKeys:{topKeys:[...]}}). The 'memory_stats fields' reference is slightly hand-wavy, 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 (Diagnose) and resource (redis memory pressure) and the concrete output (cause + action, with numbers). It explicitly positions itself as the RCA over raw metric siblings by contrasting with a 'black-box verdict', so an agent can distinguish it from redis_memory_stats or redis_big_keys without opening either 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?

Gives clear operational branching: 'Pass telemetry for pure analysis, or a target to pull live', plus the used_pct threshold semantics. It does not name specific sibling alternatives (e.g. redis_memory_stats as the raw-data counterpart) or state when-not-to-use, so it falls short of a 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?

The readOnlyHint annotation already establishes the safety profile, and the '[READ]' prefix merely restates it. The description does add value by naming the metrics returned (used vs maxmemory, eviction policy, fragmentation, peaks), but says nothing about permissions, target resolution failures, or whether it hits a live server versus cached config.

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?

Two short blocks, front-loaded with the read-only marker and the payload summary before the argument note. Nearly every word earns its place; the only slight redundancy is '[READ]' duplicating readOnlyHint.

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 no output schema, the description does the minimum necessary by enumerating the metrics returned, and the one optional parameter is explained. It stops short of describing return shape or format, but for a simple single-parameter read tool this is close to sufficient.

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 carry the full burden for the single 'target' parameter — and it does, explaining it is a Redis target name from config and that omitting it uses the default. This is exactly the compensation the low coverage requires, though it doesn't hint at valid target naming or error behavior.

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 (reads Redis memory posture) and enumerates the reported facets: used vs maxmemory, eviction policy, fragmentation, peaks. It is clearly a read-only snapshot tool, but it never contrasts itself with the sibling redis_memory_pressure_rca, which sounds like it answers a related question.

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, no stated exclusions, and no named alternative. The only usage-like text ('omit for the default') is parameter guidance rather than a condition for choosing this tool over redis_memory_pressure_rca or redis_server_info.

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?

The readOnlyHint=true annotation already establishes the safety profile, and the '[READ]' marker is concordant with it. The description adds value by enumerating the response content (version, role, clients, ops/sec, hit rate), which matters since there is no output schema, but it says nothing about auth requirements, rate limits, or behavior when the target is unreachable.

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 read marker and the resource, followed by a tightly scoped content list, then a single-line Args note. Every clause earns its place and there is no redundancy.

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 single-parameter, zero-required read tool with annotations already declaring readOnlyHint and no output schema, the description covers purpose, returned fields, and the lone parameter. It is essentially complete; only cross-tool routing among the many redis siblings is absent.

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 carry the parameter burden, and it does: 'target: redis target name from config; omit for the default' fully explains the single optional parameter, including the omit-for-default semantics that the schema only implies via default: null. It could go further by describing the config source or naming behavior, so 4 rather than 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 (read) and resource (server identity + health) and enumerates the exact content returned: version, role, clients, ops/sec, hit rate. This clearly separates it from narrower siblings such as redis_memory_stats, redis_clients, or redis_keyspace. It stops short of explicitly naming an alternative tool, so it lands at 4 rather than 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 contains no when-to-use or when-not-to-use guidance and names no alternative among the many redis_* siblings. The only guidance offered is parameter-level ('omit for the default'), which is not usage routing. An agent must infer that this is the general-purpose starting-point tool.

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?

Beyond readOnlyHint=true, the description discloses a hard cap (128 entries), the ordering (slowest first), and the envelope shape with a 'truncated' flag and an explicit warning not to treat the result as complete. That truncation warning is a meaningful behavioral disclosure the annotations do not cover; only auth/permission context and pagination mechanics are absent.

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 one-line purpose, then structured Args and Returns sections with no filler. The return-envelope paragraph is longer than strictly needed but earns its place because there is no output schema; the caveat sentence is the most valuable line in the definition.

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 0% schema coverage and no output schema, the description fully compensates by documenting both parameters and the return envelope including the truncation flag. What is missing is routing guidance relative to the many sibling RCA/diagnostic tools, which is the only real gap for an agent deciding whether to call it.

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 carry the load, and it does: 'count' is explained as max entries with a 128 cap, and 'target' as a config target name whose omission selects the default. Both parameters gain meaning not present in the bare schema, though defaults are not restated.

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 ('Recent SLOWLOG entries') plus an ordering guarantee ('slowest first'), and the [READ] prefix signals the operation class. An agent can distinguish this from redis_latency_rca, redis_server_info, and the other redis diagnostics 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 never says when to reach for this tool versus siblings like redis_latency_rca or redis_memory_pressure_rca, nor any preconditions. Only implicit context ('slowlog') suggests a latency-diagnosis scenario. No exclusions or alternative routing are 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?

Goes well beyond the annotations: it discloses the read-first behavior, the undo semantics (restores prior fields or deletes if newly created), reversibility, and the dry_run preview. This is exactly the kind of behavioral context an agent needs for a mutating 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?

Front-loaded tags and a tight behavioral paragraph, then a clean Args list. Slightly verbose repetition of field meaning but every line carries information.

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-param mutation tool with no output schema and 0% schema coverage, the description covers behavior, reversibility, preview, and all parameters. It does not describe successful return shape or error cases, but the undo/preview disclosure is the higher-value context here.

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. It documents every parameter including non-obvious ones (default vhost '/', apply_to enum values, priority semantics, definition example, target resolution), giving real meaning the bare schema lacks.

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 ('Create/update a rabbitmq policy') and distinguishes itself from the sibling delete_policy by framing the operation as create/update. The [WRITE] tag and risk annotation front-load the action type.

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 usage through the WRITE tag and the dry_run preview hint, but never explicitly states when to use this versus list_policies, delete_policy, or other mutation siblings. No exclusions or prerequisites 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?

Annotations already declare destructive=true, idempotent=false, readOnly=false; the description adds that the inverse executes through its own governed tool and risk tier (audit behavior) and that tokens are single-use. Useful beyond the annotations, though it doesn't say what the inverse might mutate.

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 [WRITE][risk=medium] tag front-loads the mode and risk, and the body is tight. The Args block partially restates the schema titles, but each line adds semantics, 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?

No output schema, but the description explains the dispatch model, the dry-run preview path, and the one-time token constraint, which covers the essentials for a mutation tool. It could clarify failure behavior (e.g., applying an already-used token) to be fully 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 carry the load, and it documents all three params: undo_id's source, dry_run's preview semantics, and target's pass-through role. The 'target' explanation ('when it accepts a target') is a bit thin but directionally 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?

States a specific verb ('apply') and resource ('a recorded undo') plus the mechanism (dispatching its inverse tool). This clearly distinguishes it from the sibling undo_list, which only enumerates tokens.

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?

Gives concrete guidance: undo_id comes from undo_list or an _undo_id in a write result, use dry_run=True to preview, and a token can only be applied once. It stops short of saying when not to use it or when preview is mandatory, but the context is clear.

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?

Annotations only supply readOnlyHint=true; the description goes well beyond that by disclosing the return shape, that truncation is *measured* via an extra-row fetch, and that effectVerified=false means the reversed change is only PROBABLE, with a caution to check live state and not over-report. This is meaningful operational context the annotations cannot carry.

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 the sibling handoff, then structured paragraphs for return value and the effectVerified caveat. Every sentence carries information, though the emphasis on truncation being 'measured, not guessed from a length coincidence' is slightly verbose for the value it adds.

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 no output schema present, the description supplies the return JSON shape, the meaning of every field an agent must act on (returned, limit, truncated, effectVerified), and the follow-up behavior for truncation. Nothing needed to call or interpret it correctly 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 description coverage is 0% and no param has an enum, so the description must compensate, and it does fully: limit is documented as default 50 / capped at 500, and target is documented as ignored with the reason (host-local undo state, kept for CLI uniformity).

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 ('List recorded, not-yet-applied undo tokens') plus ordering ('most recent first'). The [READ] tag and the reference to undo_apply make it clearly distinguishable from the sibling that actually applies tokens.

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 routes the agent: 'Use the undoId with undo_apply.' and tells it to re-run with a higher limit when truncated rather than reporting a partial list as complete. It lacks an explicit 'when not to use this' condition, so it falls just short of a 5.

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