What can you do with this server?

Queue-Inspector-MCP is an MCP server that lets an AI agent inspect and operate Redis-backed job queues (Asynq and BullMQ) through a structured interface. * List queues (list_queues): Discover all queues in Redis, tagged with their backend (asynq or bullmq). * Get queue statistics (queue_stats): See job counts per state for a given queue, using each backend's native state names (e.g., pending/archived for Asynq; waiting/failed for BullMQ). * Browse jobs by state (list_jobs): Page through jobs in a specific state, with id, type, attempt count, and a truncated last error. * Inspect a specific job (get_job): Retrieve full details for a single job — payload (base64-encoded if binary), attempt count, retry ceiling, last error, and timestamps. * Retry a failed job (retry_job, mutating): Move a failed or dead job back to the pending/wait queue, replicating each backend's own retry logic. * Delete a job (delete_job, mutating): Permanently remove a job from a queue (active jobs cannot be deleted). * Read-only mode: Use --read-only or QUEUE_INSPECTOR_READ_ONLY=1 to disable mutating tools (retry_job, delete_job) for production safety. * The backend argument is optional when the queue name is unique across both backends.

Which integrations are available for this server?

Provides tools for inspecting and operating Redis-backed job queues, supporting Asynq and BullMQ backends, including listing queues, viewing job details, and retrying/deleting jobs.

How do I use queue-inspector-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@queue-inspector-mcp List all queues with job counts" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

queue-inspector-mcp

by Yusufihsangorgel

Overview Schema Related Servers Score Discussions

TypeScript

Remote

queue-inspector-mcp

npm

An MCP server that lets an agent inspect and operate Redis-backed job queues. It speaks to three backends today, Asynq (Go) and BullMQ (Node) and Sidekiq (Ruby): per-state counts, individual job detail, and moving jobs between states — six tools over stdio, with a --read-only mode that drops the mutating ones entirely.

When a queue misbehaves in production, the useful questions are about jobs, not keys: how many tasks are stuck in retry, what error a specific job failed with, whether a dead job can be requeued. A generic Redis MCP server shows you keys and raw values; this one understands Asynq's protobuf task messages and BullMQ's state structures, and Sidekiq's inline job JSON, so an agent can answer those questions directly.

What this looks like from the agent side. The tool output below is recorded, not mocked: a local Redis seeded with real Asynq tasks, an SMTP relay down, and one delivery out of attempts.

> smtp relay was down earlier, it's back now - did we strand anything in the default queue?

⏺ queues - queue_stats (MCP)(queue: "default")
  ⎿  { "queue": "default", "backend": "asynq", "states": { "pending": 0, "active": 0,
       "scheduled": 6, "retry": 38, "archived": 1, "completed": 57 } }

⏺ 38 tasks are stuck in retry and one is archived. Sampling the retries to see why.
⏺ queues - list_jobs (MCP)(queue: "default", state: "retry", limit: 3)
  ⎿  { …, "count": 3, "jobs": [
       { "id": "46c6ba86-…", "type": "email:deliver", …, "attempts": 5, "maxRetries": 25,
         "lastError": "dial tcp 127.0.0.1:2525: connect: connection refused" }, … ] }

⏺ Every sampled retry is email:deliver failing to reach the relay; those re-run on their own
  now that it's back. The archived task is out of attempts — it never will.
⏺ queues - list_jobs (MCP)(queue: "default", state: "archived", limit: 1)
  ⎿  { …, "count": 1, "jobs": [ { "id": "814cc556-04a8-4923-8de5-71a661c6063c", … } ] }
⏺ queues - get_job (MCP)(queue: "default", id: "814cc556-04a8-4923-8de5-71a661c6063c")
  ⎿  { …, "type": "email:deliver", "state": "archived", …, "attempts": 8, "maxRetries": 8,
       …, "fullError": "dial tcp 127.0.0.1:2525: connect: connection refused",
       "timestamps": { …, "lastFailedAt": "2026-07-10T14:01:40.000Z", … },
       "payload": "{\"to\":\"dana@example.test\",\"template\":\"receipt\"}", … }

⏺ A receipt email that burned all 8 attempts during the outage. Requeuing it.
⏺ queues - retry_job (MCP)(queue: "default", id: "814cc556-04a8-4923-8de5-71a661c6063c")
  ⎿  { "ok": true, "message": "asynq task 814cc556-04a8-4923-8de5-71a661c6063c moved to
       pending in queue \"default\"" }

⏺ queues - queue_stats (MCP)(queue: "default")
  ⎿  { "queue": "default", "backend": "asynq", "states": { "pending": 1, "active": 0,
       "scheduled": 6, "retry": 38, "archived": 0, "completed": 57 } }
⏺ The receipt is back in pending. The other 38 will re-run as their backoff timers come due.

Background: I wrote up the design decisions behind this — why jobs, not keys, and the read-only posture — on my blog.

Architecture

---
config:
  look: handDrawn
---
flowchart LR
    A["AI agent"] -->|"MCP · stdio"| M["queue-inspector-mcp"]
    M --> B1["Asynq adapter<br/>protobuf msg"]
    M --> B2["BullMQ adapter<br/>state by zset"]
    M --> B3["Sidekiq adapter<br/>job JSON in lists + zsets"]
    B1 -->|ioredis| R[("Redis")]
    B2 -->|ioredis| R
    M -.->|"--read-only<br/>drops mutating tools"| G{{"prod-safe"}}

The server speaks MCP over stdio to the agent and talks to Redis through per-backend adapters that understand each library's Redis key layout — Asynq's protobuf task messages, BullMQ's state-by-membership sorted sets, and Sidekiq's inline job JSON — instead of treating Redis as a bag of keys.

Related MCP server: MCP-Serveur

Why an MCP server instead of the CLI

Asynq ships a CLI, and redis-cli can read anything. But wiring a CLI into an agent means giving the agent a shell. The tools here return structured JSON the model can reason over rather than aligned text to re-parse; they work in clients that have no shell, like Claude Desktop; and read-only is enforced by construction — under --read-only the mutating tools are not in tools/list at all, which is a stronger guarantee than a confirmation prompt a model can talk its way past.

Install

Requires Node.js 18 or newer and a reachable Redis.

npm install -g queue-inspector-mcp
# or run without installing:
npx queue-inspector-mcp

Configure

The server talks MCP over stdio, so it works with any MCP client. Point your client at the queue-inspector-mcp binary and set REDIS_URL.

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "queues": {
      "command": "npx",
      "args": ["-y", "queue-inspector-mcp"],
      "env": { "REDIS_URL": "redis://localhost:6379", "QUEUE_INSPECTOR_READ_ONLY": "1" }
    }
  }
}

Claude Code (project .mcp.json, or claude mcp add):

{
  "mcpServers": {
    "queues": {
      "command": "npx",
      "args": ["-y", "queue-inspector-mcp"],
      "env": { "REDIS_URL": "redis://localhost:6379", "QUEUE_INSPECTOR_READ_ONLY": "1" }
    }
  }
}

Both examples are read-only. To enable retry_job and delete_job, remove QUEUE_INSPECTOR_READ_ONLY.

Configuration

Variable	Default	Purpose
`REDIS_URL`	`redis://localhost:6379`	Redis connection string. Include a database number, e.g. `redis://localhost:6379/2`.
`ASYNQ_PREFIX`	`asynq`	Key prefix Asynq was configured with.
`BULL_PREFIX`	`bull`	Key prefix BullMQ was configured with.
`SIDEKIQ_PREFIX`	(none)	Key prefix Sidekiq was configured with, if namespaced.
`QUEUE_INSPECTOR_BACKENDS`	`asynq,bullmq,sidekiq`	Restrict which backends are scanned.
`QUEUE_INSPECTOR_READ_ONLY`	unset	Set to `1` (or pass `--read-only`) to omit the mutating tools.

Tools

Tool	Mutating	Behavior
`list_queues`	no	List every detected queue, tagged with its backend.
`queue_stats`	no	Count jobs per state for a queue, using the backend's own state names.
`list_jobs`	no	Page through jobs in one state; returns id, type, attempts, and a truncated last error.
`get_job`	no	Full detail for one job: payload, attempts, retry ceiling, last error, timestamps.
`retry_job`	yes	Move a failed or dead job back to pending/wait so it runs again.
`delete_job`	yes	Permanently delete a job. Active jobs are refused.

When a queue name is unique across the enabled backends, the backend argument is optional; the server resolves it. If the same name exists in more than one backend, pass backend explicitly.

Read-only mode

With --read-only or QUEUE_INSPECTOR_READ_ONLY=1, the server never registers retry_job or delete_job. The mutating tools are absent from tools/list entirely, so a client cannot call them by mistake. This is the recommended configuration for pointing an agent at a production Redis.

Backend state names

The two libraries model job lifecycles differently, so this server does not invent a shared vocabulary. It reports each backend's own state names, and each state maps to a specific Redis structure.

A job moves through these states over its lifetime (Asynq shown):

---
config:
  look: handDrawn
---
stateDiagram-v2
    [*] --> pending: enqueue
    pending --> active: worker picks up
    active --> completed: success
    active --> retry: handler error
    retry --> active: backoff elapsed
    retry --> archived: retries exhausted
    archived --> pending: retry_job
    completed --> [*]

Asynq:

State	Meaning	Redis structure
`pending`	Ready to run, waiting for a worker	list `asynq:{q}:pending`
`active`	Currently being processed	list `asynq:{q}:active`
`scheduled`	Enqueued for a future time	zset `asynq:{q}:scheduled`
`retry`	Failed, waiting to be retried	zset `asynq:{q}:retry`
`archived`	Retries exhausted (the "dead" state)	zset `asynq:{q}:archived`
`completed`	Finished, kept for its retention window	zset `asynq:{q}:completed`

BullMQ:

State	Meaning	Redis structure
`waiting`	Ready to run	list `bull:q:wait`
`active`	Currently being processed	list `bull:q:active`
`delayed`	Scheduled for a future time	zset `bull:q:delayed`
`prioritized`	Waiting, ordered by priority	zset `bull:q:prioritized`
`waiting-children`	Blocked on child jobs (flows)	zset `bull:q:waiting-children`
`paused`	Held while the queue is paused	list `bull:q:paused`
`completed`	Finished successfully	zset `bull:q:completed`
`failed`	Failed after exhausting attempts	zset `bull:q:failed`

Asynq's archived is what most people mean by a "dead" job. list_jobs returns Asynq's terminal sets in Redis (score) order and BullMQ's completed/failed sets most-recent-first.

Compatibility

Node.js 18 or newer; any MCP client that speaks stdio. CI runs the integration suite against Redis 7.
retry_job and delete_job run each library's own Lua, vendored verbatim with provenance headers: reprocessJob and removeJob from BullMQ 5.79.3, runTask and deleteTask from Asynq v0.25.1.
The integration tests read and mutate jobs produced by those same versions of the real libraries — the verify/ producers lock BullMQ 5.79.3 and Asynq v0.25.1.
BullMQ 4.x is untested: the adapter reads the v5 hash layout (attempts live in atm, where v4 used attemptsMade).

What this doesn't do

Only Asynq and BullMQ are supported. Sidekiq, Celery, RQ and others are not.
No web UI. This is an MCP server for programmatic use; it is not a dashboard.
No streaming or watch. Each tool call is a point-in-time read; there is no subscription to queue events.
retry_job and delete_job faithfully replicate each library's own mechanism rather than reimplementing it. Retry runs Asynq's Inspector.RunTask script and BullMQ's Job.retry (reprocessJob) script; delete runs Asynq's Inspector.DeleteTask script and BullMQ's Job.remove (removeJob) script. As a result the semantics match the libraries: retrying a BullMQ job applies only to failed/completed jobs and does not reset attemptsMade (matching Job.retry()); neither backend can retry or delete an active job.
delete_job removes a single BullMQ job and does not cascade into a flow's children.
Asynq group aggregation (the aggregating state) is not surfaced in this release.

Alternatives

bullmq-mcp — MCP server for BullMQ only; no read-only mode.
Workbench — a BullMQ dashboard whose MCP support is an HTTP proxy into a running Workbench instance. If you are BullMQ-only and want a UI, it is the better choice.
Asynqmon — Asynq's web dashboard, not an MCP server; no commits since May 2024.
mcp-redis — the official Redis MCP server; operates on keys and values, not jobs.

As of this writing there is no other MCP server that speaks Asynq — a 13.5k-star library whose dashboard has been dormant since 2024 — and none that reads both wire formats from one process.

License

MIT © Yusuf İhsan Görgel

Available Tools

6 tools

delete_jobDelete jobA

Destructive

Permanently delete a job from a queue. Active jobs cannot be deleted. Faithfully replicates the backend's own delete (asynq Inspector.DeleteTask, bullmq Job.remove).

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Job or task id.
`queue`	Yes	Queue name, as reported by list_queues.
`backend`	No	Which backend owns the queue. Optional when the queue name is unique across backends.

TDQS

A4.2/5.0

Behavior4/5

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

The description adds context beyond the destructiveHint annotation, stating the deletion is permanent and cannot delete active jobs. It also mentions replicating backend behavior, which is useful for understanding side effects.

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 extremely concise with two sentences, front-loading the main action and constraints. No superfluous information.

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

Completeness4/5

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

For a delete operation, the description covers key constraints and backend fidelity. It lacks information about the return value or error behavior, but the context is sufficient for a simple tool.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already describes all parameters. The description does not add additional semantics beyond what is in the schema.

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 clearly states the action 'permanently delete' and the resource 'job from a queue'. It distinguishes from siblings like get_job, list_jobs, retry_job by specifying deletion and noting that active jobs cannot be deleted.

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 explicitly says 'Active jobs cannot be deleted', providing a clear when-not condition. However, it does not explicitly guide when to use this tool over alternatives like retry_job or list_jobs.

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

get_jobGet jobA

Read-only

Fetch full detail for one job: payload, attempts, retry ceiling, last error and timestamps. Binary payloads are returned base64-encoded and flagged.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Job or task id.
`queue`	Yes	Queue name, as reported by list_queues.
`backend`	No	Which backend owns the queue. Optional when the queue name is unique across backends.

TDQS

A4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, and the description aligns with a read operation. The description adds behavioral context beyond annotations by noting that binary payloads are base64-encoded and flagged. No contradictions.

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?

Two sentences that are concise and front-loaded. The first sentence communicates the core purpose and visible outputs, the second adds an important detail about binary encoding. No extraneous information.

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

Completeness4/5

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

The description adequately explains what the tool returns with specific fields and handles binary payloads. Given no output schema, this is sufficient for a single-job detail retrieval. However, it could mention the return format (e.g., JSON object) for completeness.

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

Parameters3/5

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

Schema coverage is 100% with clear descriptions for each parameter (id, queue, backend). The description does not add additional meaning to parameters beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 uses a specific verb 'Fetch' and resource 'full detail for one job', listing specific fields (payload, attempts, retry ceiling, last error, timestamps). This clearly distinguishes it from siblings like list_jobs (list of jobs) or delete_job (delete).

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

Usage Guidelines3/5

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

The description implies usage for retrieving detailed information about a specific job but does not explicitly state when to use this tool versus alternatives like list_jobs, retry_job, or delete_job. No exclusions or prerequisites are mentioned.

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

list_jobsList jobsA

Read-only

List jobs in a given state (paged). Returns id, type, attempts and a truncated last error. Valid states depend on the backend: asynq uses pending/active/scheduled/retry/archived/completed; bullmq uses waiting/active/delayed/prioritized/waiting-children/paused/completed/failed.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum jobs to return.
`queue`	Yes	Queue name, as reported by list_queues.
`state`	Yes	State to list, e.g. "failed" (bullmq) or "archived" (asynq).
`offset`	No	Number of jobs to skip.
`backend`	No	Which backend owns the queue. Optional when the queue name is unique across backends.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true; the description adds that results are paged and include id, type, attempts, and a truncated last error. This provides behavioral context beyond the annotation, such as truncation behavior.

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 two sentences: the first states the core purpose, the second adds backend-specific state details. It is front-loaded and contains no extraneous information.

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

Completeness4/5

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

Given 5 parameters and no output schema, the description covers the return fields and pagination hint. It is sufficient for a list tool, though it could mention default sorting or ordering, but not necessary.

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?

Schema coverage is 100%, so baseline is 3. The description adds value by enumerating backend-specific states and clarifying the optionality of the backend parameter. This supplements the schema descriptions.

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 clearly states the tool lists jobs filtered by state, with pagination. It specifies the verb (list), resource (jobs), and scope (by state, paged). It uniquely distinguishes from sibling tools like delete_job or get_job.

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 provides explicit valid states for each backend, guiding proper use. It does not include explicit when-not-to-use or alternatives, but the context is clear enough for correct invocation.

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

list_queuesList queuesA

Read-only

List every queue the inspector can see, tagged with its backend (asynq or bullmq).

ParametersJSON Schema

Name	Required	Description	Default
`backend`	No	Which backend owns the queue. Optional when the queue name is unique across backends.

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so description's mention of 'the inspector can see' adds marginal value. Mention of backend tagging provides some output behavior detail but lacks disclosure of pagination, rate limits, or access restrictions.

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 a single, well-structured sentence that immediately conveys the tool's action and key feature (backend tags). No extraneous text.

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

Completeness3/5

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

Given no output schema, the description partially compensates by noting output includes backend tags, but doesn't specify other returned fields or structure. Adequate for a simple list tool but not fully complete.

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

Parameters3/5

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

Schema has 100% description coverage for the single parameter 'backend' (with enum). Description adds no extra parameter semantics beyond schema, so baseline 3 is appropriate.

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 clearly states the tool lists every queue visible to the inspector, with a specific detail about tagging with backend type. This distinguishes from sibling tools focused on jobs or queue statistics.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, such as queue_stats or other queue-related tools. The description only states functionality, not context of use.

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

queue_statsQueue statsA

Read-only

Report the number of jobs in each state for a queue, using the backend's own state names.

ParametersJSON Schema

Name	Required	Description	Default
`queue`	Yes	Queue name, as reported by list_queues.
`backend`	No	Which backend owns the queue. Optional when the queue name is unique across backends.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint: true, so the agent knows this is a safe read operation. The description adds behavioral context by stating 'using the backend's own state names', which warns that state names are backend-specific (asynq vs bullmq). However, it does not disclose error behavior when the queue is missing or missing backend parameter, but given the simplicity of the tool, this is acceptable.

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 a single sentence of 13 words that is front-loaded with the verb and resource. Every word is necessary and contributes to understanding. No fluff or redundancy.

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

Completeness3/5

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

Given the tool has no output schema, the description could have briefly mentioned that the output is a mapping from state names to counts. However, the tool is simple (2 params, 1 required), and the core purpose is clear. The absence of output details is a minor gap but not critical.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on individual parameters beyond the schema. It implicitly references the 'queue' parameter but does not add meaning or context for the 'backend' parameter (e.g., when it is optional).

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 uses a specific verb 'Report' and clearly identifies the resource: 'number of jobs in each state for a queue'. It also notes 'using the backend's own state names', which adds precision and distinguishes the tool from siblings like list_jobs or get_job that deal with individual jobs rather than aggregate state counts.

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

Usage Guidelines3/5

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

The description implies usage for obtaining queue statistics but provides no explicit guidance on when to use this tool versus alternatives such as list_jobs or list_queues. There is no mention of prerequisites, when not to use it, or how it differs from sibling tools like get_job or retry_job.

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

retry_jobRetry jobA

Idempotent

Move a failed or dead job back to the pending/wait queue so it runs again. Faithfully replicates the backend's own retry (asynq Inspector.RunTask, bullmq Job.retry).

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Job or task id.
`queue`	Yes	Queue name, as reported by list_queues.
`backend`	No	Which backend owns the queue. Optional when the queue name is unique across backends.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate idempotentHint=true and destructiveHint=false, so the description adds value by explaining the effect (moving to pending queue) and faithfulness to backend retry. It does not contradict annotations. Would benefit from stating constraints like job must be in a retryable state.

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?

Two concise sentences: first states purpose clearly, second reinforces behavioral accuracy with backend reference. No unnecessary words.

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

Completeness4/5

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

The tool has no output schema but annotations cover safety. The description explains the outcome (job moved to pending queue). For a simple mutation, this is mostly complete, though returning a success indicator would be helpful.

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

Parameters3/5

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

Schema coverage is 100% with clear descriptions for each parameter (id, queue, backend). The description does not add new meaning beyond the schema, so baseline 3 is appropriate.

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 clearly states the tool's action ('Move a failed or dead job back to the pending/wait queue') and target resource ('failed or dead job'). It distinguishes itself from sibling tools like delete_job (removal) and get_job (reading) by focusing on retrying a job.

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 implies usage for retrying failed/dead jobs and references backend retry functions, providing context. However, it lacks explicit guidance on when not to use the tool (e.g., if the job is already pending) or direct comparison with alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jul 8, 2026
- First observeddelete_job
- First observedget_job
- First observedlist_jobs
- First observedlist_queues
- First observedqueue_stats
- First observedretry_job

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct operation: delete, get, list jobs, list queues, stats, retry. No two tools have overlapping purposes, and their descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., delete_job, list_queues, queue_stats). The naming is predictable and uniform.

Tool Count5/5

Six tools are well-scoped for a queue inspector: basic inspection (list queues, list jobs, get job, stats) and two common actions (delete, retry). The count is appropriate for the domain.

Completeness4/5

The tool surface covers the core inspector operations: enumerating queues, listing and viewing jobs, retrieving stats, deleting, and retrying. Minor gaps like bulk operations or moving jobs to arbitrary states exist, but overall coverage is strong.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
AgentMarketplace A
io.github.raditotev
MCP Server for an Agent Task Marketplace
Autonomous Agents Agent Orchestration
221
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
turva-mcp A
dev.turva
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Autonomous Agents Security Developer Tools
42

Related MCP Servers

A2AMCP
Autonomous Agents Agent Orchestration Developer Tools
webdevtodayjason
A
license
Not graded
quality
C
maintenance
A Redis-backed MCP server that enables multiple AI agents to communicate, coordinate, and collaborate while working on parallel development tasks, preventing conflicts in shared codebases.
Updated a year ago (2025-06-09 18:28 UTC)
20
MIT
MCP-Serveur
Developer Tools App Automation
DeamonDev888
F
license
Not graded
quality
F
maintenance
A modular and extensible MCP server for managing synchronous and asynchronous tasks, leveraging Docker, BullMQ, and Redis.
Updated a year ago (2025-07-08 00:44 UTC)
4
-
mcp-redis-monitor
Monitoring Observability
antonio-mello-ai
A
license
A
quality
B
maintenance
FastMCP server with read-only tools to monitor Redis — queue depths, Celery queue status, connected clients, server/memory info, and per-database key counts
Updated 21 days ago (2026-08-17 00:44 UTC)
5
3
MIT
Redis MCP Server
Databases Developer Tools
minivv
F
license
C
quality
C
maintenance
A Model Context Protocol (MCP) server for Redis. Connect to any Redis instance and execute queries through AI assistants.
Updated 2 months ago (2026-06-26 06:17 UTC)
30
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Yusufihsangorgel/queue-inspector-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server