list_workers

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by detailing the return structure (state, job ID, heartbeat, counters) and the optional filter behavior, providing more than the annotations alone. It does not contradict the annotations.

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

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

The description is dense but organized: front-loads the primary action, enumerates return fields in a list, and then clarifies parameter behavior. Every sentence earns its place, and there is no redundant phrasing or 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?

Given a single optional parameter and an output schema already present, the description fully covers what the tool does, what it returns, and how the parameter affects results. Nothing an agent needs to call it correctly is missing, and the prose return-field enumeration complements the output schema rather than repeating 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 compensate for parameter meaning. It does: 'If `queue` is given, only workers listening to that queue are returned' fully explains the effect of the single optional parameter. No further syntax is needed for a string parameter, and the default null is implicit 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?

The description clearly states the tool lists currently registered RQ workers with an optional queue filter, and enumerates the exact per-worker fields returned (name, state, queues, current job ID, heartbeat, counters). This is a specific verb+resource that is plainly distinct from sibling tools like get_worker (singular worker) or list_jobs (jobs).

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 optional 'queue' parameter's effect (only workers listening to that queue are returned) but does not explicitly mention when to use this tool versus alternatives such as get_worker or list_queues. The purpose is clear enough that an agent can infer usage, but it lacks explicit exclusionary guidance.

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