rq-mcp

get_queue

Read-onlyIdempotent

Retrieve detailed status for a specific Redis Queue by name, including job count by status, age of the oldest queued job, and default timeout. Unknown queues return zero counts instead of errors.

Instructions

Return detailed status for a single queue by name.

Includes the same per-status counts as list_queues, the age in seconds of the oldest still-queued job (null if empty), and default_timeout in seconds (reflects this server's own default, since RQ does not persist a per-queue default_timeout to Redis). An unknown queue name is not an error -- RQ queues are lazy/virtual, so it returns the same shape with all counts at 0.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses meaningful behaviors: the age of the oldest queued job and null when empty, the default_timeout nuance regarding RQ persistence, and the important edge case that unknown queue names are valid and return zero counts. This is substantial added context.

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

Conciseness5/5

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

The description is front-loaded with the core purpose and the subsequent sentences each add non-redundant, useful details. Referencing list_queues instead of restating count fields keeps it efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a simple single-queue status tool: it covers the fields returned, an important edge case, and a subtle behavior about default_timeout. The presence of an output schema means return-value details do not need to be duplicated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description must carry the meaning of the single 'name' parameter. It does so by explaining that the parameter identifies the queue and that unknown names are not errors. It does not provide format constraints, but none are needed beyond string type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb ('Return') and resource ('detailed status for a single queue by name'), making the tool's scope immediately clear. It also references list_queues to clarify the relationship and differentiates this tool as the single-queue counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

The description clearly implies the use case: query one queue's status by name, and it references list_queues for the multi-queue context. It does not explicitly state when not to use this tool or name alternative decision rules, 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.

Deploy Server