What is the Workbench MCP server?

@getworkbench/mcp is an open-source Model Context Protocol server that lets AI agents — Cursor, Claude Desktop, Zed, Continue.dev, and any other MCP client — inspect, debug, and operate BullMQ queues through a running Workbench dashboard. It ships 18 tools split between read-only inspection and gated destructive operations, runs locally over stdio, and reuses the dashboard's existing Basic Auth and readonly flag instead of introducing a new permission model.

Which AI editors and agents does it work with?

Any MCP-aware client. The package is verified against Cursor, Claude Desktop, Zed, and Continue.dev, and works the same way with VS Code's Copilot agent, Goose, and other MCP runtimes because the server speaks the standard JSON-RPC over stdio protocol. Install instructions for each editor live in the package README at github.com/pontusab/workbench/tree/main/packages/mcp.

Does the Workbench MCP need its own Redis connection?

No. The MCP is a thin HTTP proxy in front of a running Workbench dashboard — it never talks to Redis directly. You configure it with a single WORKBENCH_URL pointing at your dashboard (and optionally the same Basic Auth credentials the dashboard already uses). All BullMQ work happens server-side inside the dashboard, so there's no second connection pool to manage and no second source of truth for queue config.

Does the MCP respect the dashboard's readonly mode?

Yes, end-to-end. When the dashboard is started with readonly: true it rejects every write operation with a 403, and the MCP surfaces that 403 to the calling agent as an actionable error message explaining that the dashboard is in readonly mode. The agent can still call every inspect tool — list queues, inspect jobs, read metrics — but cannot retry, remove, pause, enqueue, or trigger schedulers until readonly is disabled.

What tools does the Workbench MCP expose?

18 tools across two intents. Inspect (readOnlyHint): workbench_get_overview, list_queues, get_quick_counts, get_metrics, get_activity, list_jobs, list_runs, get_job, search_jobs, list_schedulers, list_flows, get_flow, list_tag_values. Operate (destructiveHint): workbench_retry_job, remove_job, promote_job, pause_queue, resume_queue, run_scheduler_now, enqueue_job, clean_jobs, bulk_retry, bulk_delete. Clients use the annotations to auto-approve reads and prompt before writes.

Is the Workbench MCP free and open source?

Yes. @getworkbench/mcp is MIT-licensed, ships on npm, and the source lives at github.com/pontusab/workbench/tree/main/packages/mcp. There is no paid tier, no telemetry, and no account required — same as the rest of the Workbench project.

New integration

Drive BullMQ from your editor

Workbench 0.5.1 ships @getworkbench/mcp — a Model Context Protocol server that lets Cursor, Claude Desktop, Zed, and Continue.dev see, debug, and operate your BullMQ queues from the same chat box you already use for code.

May 26, 2026

Workbench 0.5.1 ships @getworkbench/mcp — a Model Context Protocol server that lets Cursor, Claude Desktop, Zed, Continue.dev, and any other MCP-aware agent see, debug, and operate your BullMQ queues from the same chat box you already use for code.

Workbench already gives developers a beautiful BullMQ dashboard. The MCP gives agents the same surface. Same data, same operations, same permissions — but reachable from your editor.

What it lets the agent do

Real prompts the MCP unlocks today:

“Why is email-send backed up?” — the agent calls workbench_get_metrics, sees p95 latency spiked at 14:02, calls workbench_list_runs with status=failed and from=14:00, finds the regression in the stack trace.
“Retry every failed webhook-deliver from the last hour.” — workbench_list_runs then workbench_bulk_retry.
“Run the nightly billing scheduler now so I can verify the fix.” — workbench_list_schedulers then workbench_run_scheduler_now, the one-off trigger added in Workbench 0.5.0.

Install in 30 seconds

The MCP is a tiny npx-runnable binary — no global install, no port to manage. In Cursor, drop the following into ~/.cursor/mcp.json:

{
  "mcpServers": {
    "workbench": {
      "command": "npx",
      "args": ["-y", "@getworkbench/mcp"],
      "env": {
        "WORKBENCH_URL": "http://localhost:3000/jobs",
        "WORKBENCH_USERNAME": "admin",
        "WORKBENCH_PASSWORD": "hunter2"
      }
    }
  }
}

Restart Cursor and the 18 workbench_* tools appear in the chat. The same pattern works for Claude Desktop, Zed, and Continue.dev with their respective config paths — full snippets for each editor live in the package README.

Only one env var is required: WORKBENCH_URL, pointing at the URL where you'd open the dashboard in a browser. WORKBENCH_USERNAME + WORKBENCH_PASSWORD (or WORKBENCH_TOKEN) cover the same Basic Auth your dashboard was started with.

The 18 tools

Tools are grouped by intent and annotated so MCP clients know how to gate them. Inspect tools are tagged readOnlyHint: true so clients like Cursor can auto-approve them; operate tools are tagged destructiveHint: true so the user is prompted before each call.

Inspect (read-only)

workbench_get_overview: Per-queue snapshot — names, paused state, count summary.
workbench_list_queues: Queues with full per-status counts.
workbench_get_quick_counts: Lightweight counts, cheap for polling.
workbench_get_metrics: Per-queue p50 / p95 latency and throughput.
workbench_get_activity: 24h completed / failed buckets for the activity heatmap.
workbench_list_jobs: Jobs in a queue, status-filtered, paginated.
workbench_list_runs: Cross-queue runs with text, status, time, and tag filters.
workbench_get_job: Full payload + attempts + stack trace for one job.
workbench_search_jobs: Free-text search across job ids, names, and indexed tag values.
workbench_list_schedulers: Repeatable + delayed scheduler entries.
workbench_list_flows: Recent FlowProducer roots.
workbench_get_flow: Full DAG for a FlowProducer flow.
workbench_list_tag_values: Distinct values for a configured tag field.

Operate (gated, prompts the user)

workbench_retry_job: Retry a single failed job.
workbench_remove_job: Delete a job (any state).
workbench_promote_job: Force a delayed job to run now.
workbench_pause_queue: Pause a queue.
workbench_resume_queue: Resume a paused queue.
workbench_run_scheduler_now: One-off trigger for a repeatable scheduler.
workbench_enqueue_job: Add a new job to a queue.
workbench_clean_jobs: Bulk-remove completed or failed jobs.
workbench_bulk_retry: Retry many failed jobs in one call.
workbench_bulk_delete: Delete many jobs in one call.

How it works

The MCP is deliberately not a second connection to Redis. It speaks JSON-RPC over stdio to your editor (the standard MCP transport, what every client in the wild expects) and HTTP to your running Workbench dashboard — the dashboard is the one that owns the Redis connection, the auth, the readonly flag, and the queue config.

Cursor / Claude / Zed / Continue ─┐
                                         │  JSON-RPC (stdio)
                                         ▼
                                workbench-mcp
                                         │  HTTP + Basic Auth
                                         ▼
                              Workbench dashboard
                                         │  ioredis
                                         ▼
                                   Redis / BullMQ

That layering is the whole point of shipping this as an optional, separate package: no second source of truth for permissions, no parallel Redis pool to keep in sync, no duplicated business logic. If your dashboard is in readonly: true, every write tool returns a 403 the agent can show you verbatim instead of silently mutating production.

Auth and readonly are inherited end-to-end

For unattended agents, run the dashboard with readonly: true and pass the MCP the same Basic Auth credentials. Every operate tool will refuse cleanly with an actionable error message; every inspect tool keeps working. For regular use, leave the dashboard as you already have it — the MCP will prompt before any destructive call thanks to the destructiveHint annotation.

Frequently asked questions

What is the Workbench MCP server?: @getworkbench/mcp is an open-source Model Context Protocol server that lets AI agents — Cursor, Claude Desktop, Zed, Continue.dev, and any other MCP client — inspect, debug, and operate BullMQ queues through a running Workbench dashboard. It ships 18 tools split between read-only inspection and gated destructive operations, runs locally over stdio, and reuses the dashboard's existing Basic Auth and readonly flag instead of introducing a new permission model.
Which AI editors and agents does it work with?: Any MCP-aware client. The package is verified against Cursor, Claude Desktop, Zed, and Continue.dev, and works the same way with VS Code's Copilot agent, Goose, and other MCP runtimes because the server speaks the standard JSON-RPC over stdio protocol. Install instructions for each editor live in the package README at github.com/pontusab/workbench/tree/main/packages/mcp.
Does the Workbench MCP need its own Redis connection?: No. The MCP is a thin HTTP proxy in front of a running Workbench dashboard — it never talks to Redis directly. You configure it with a single WORKBENCH_URL pointing at your dashboard (and optionally the same Basic Auth credentials the dashboard already uses). All BullMQ work happens server-side inside the dashboard, so there's no second connection pool to manage and no second source of truth for queue config.
Does the MCP respect the dashboard's readonly mode?: Yes, end-to-end. When the dashboard is started with readonly: true it rejects every write operation with a 403, and the MCP surfaces that 403 to the calling agent as an actionable error message explaining that the dashboard is in readonly mode. The agent can still call every inspect tool — list queues, inspect jobs, read metrics — but cannot retry, remove, pause, enqueue, or trigger schedulers until readonly is disabled.
What tools does the Workbench MCP expose?: 18 tools across two intents. Inspect (readOnlyHint): workbench_get_overview, list_queues, get_quick_counts, get_metrics, get_activity, list_jobs, list_runs, get_job, search_jobs, list_schedulers, list_flows, get_flow, list_tag_values. Operate (destructiveHint): workbench_retry_job, remove_job, promote_job, pause_queue, resume_queue, run_scheduler_now, enqueue_job, clean_jobs, bulk_retry, bulk_delete. Clients use the annotations to auto-approve reads and prompt before writes.
How do I install the Workbench MCP in Cursor?: Add an entry under "mcpServers" in ~/.cursor/mcp.json: { "workbench": { "command": "npx", "args": ["-y", "@getworkbench/mcp"], "env": { "WORKBENCH_URL": "http://localhost:3000/jobs", "WORKBENCH_USERNAME": "admin", "WORKBENCH_PASSWORD": "hunter2" } } }. Restart Cursor and the 18 workbench_* tools appear in the chat. The same pattern works for Claude Desktop, Zed, and Continue.dev with their respective config files — see the package README for the exact paths.
Is the Workbench MCP free and open source?: Yes. @getworkbench/mcp is MIT-licensed, ships on npm, and the source lives at github.com/pontusab/workbench/tree/main/packages/mcp. There is no paid tier, no telemetry, and no account required — same as the rest of the Workbench project.

Try it

Bring your queues into your editor.

Full setup snippets for Cursor, Claude Desktop, Zed, and Continue.dev in the package README.