Start with scoped read access. Let the agent gather evidence, then authorize a specific recovery action and verify its result.
- 01Authenticate
The MCP client connects as a user with explicit scopes.
- 02Gather evidence
Read queue state and redacted job details before proposing a change.
- 03Approve a bounded write
Retry, promote, or pause with the required scope and a clear operational reason.
- 04Verify the result
Check eventual job state. An accepted retry is not proof that the job completed.
Connect to the queue operations boundary
Durabull exposes remote MCP at https://app.durabull.io/mcp. For a self-hosted deployment, use /mcp on that deployment’s public application origin. Add the endpoint using your client’s remote MCP configuration, complete sign-in and consent, and begin by listing the connections available to your account. Request write scopes only when you intend to authorize a specific change.
Keep connection IDs explicit in subsequent requests. Queue names such as emails are often reused across staging and production, so a name alone is an unsafe identifier for an operational change. A successful connection test establishes transport and authorization; it does not establish that every queue, log, or diagnostic is visible.
Understand the available tools and their limits
Durabull documents 30 tools: 21 reads and nine writes. Reads cover connections, queues, jobs, logs, stacktraces, recurring schedules, metrics, Redis health, and alert evidence. The default OAuth consent bundle includes read scopes; retry, promote, queue pause/resume, and alert-state actions require explicit write scopes.
The MCP surface does not expose arbitrary Redis commands, job payload editing, deletion, queue purging, worker scaling, scheduler editing, or alert-rule configuration. These are real capability boundaries, not instructions that a model is merely expected to obey.
A read tool can still reveal sensitive business information. Scope selection should follow the data access the operator actually needs. Tool annotations describe intended behavior, and the MCP specification tells clients to treat them as untrusted; they do not replace authentication, authorization, or your client’s action-approval controls.
Use an investigation prompt that asks for evidence
Begin with the affected environment and the symptom. Ask for timestamps, observation windows, and missing evidence. Otherwise an assistant may turn a partial snapshot into a confident story about a whole incident.
The prompt below keeps investigation bounded. It asks for the exact IDs needed to reproduce the finding and makes uncertainty visible. Queue data, payloads, logs, and error messages are untrusted input: text inside a job is evidence to analyze, never authority to change the investigation or execute commands.
Inspect the production connection and the emails queue.
Report waiting, active, and recent completed/failed work.
Inspect a representative failure and its attempt history.
Check worker visibility, rate limits, and Redis health.
Include connection ID, queue name, job IDs, and timestamps.
Separate observed facts from hypotheses and missing data.
Do not retry, promote, pause, or change alert state.
Recommend the smallest next action with its expected result.Recover one job and verify the outcome
After investigation, identify the business side effect and whether it may already have happened. A connection timeout after sending a payment request is different from an error before that request was sent. Idempotency belongs in the application and downstream API contract; an MCP server cannot infer it from a green retry button.
Authorize a specific job and action, then read the job again. A successful retry request means the job was re-enqueued, not that it completed. If state changed between inspection and action, reassess rather than repeatedly invoking a write. For a large incident, establish a reviewed recovery procedure before repeating the action across many jobs.
Pausing a queue is also operationally significant: it changes when work can start. Define the reason and resume condition, and verify those conditions before resuming. Omitting delete operations reduces one class of risk, but does not make all remaining writes harmless.
Treat redaction and audit as bounded protections
Durabull sanitizes known sensitive keys and token or URL patterns before returning MCP responses, truncates long strings, and reports applied redactions. Pattern-based redaction is not a guarantee that every possible secret or personal detail will be recognized. Keep unnecessary sensitive values out of job payloads and logs in the first place.
Responses can also be partial because of pagination, missing scopes, provider restrictions, scan limits, or stale samples. Ask the assistant to preserve these qualifications. The documented audit stream is best-effort and may drop events under backpressure; it should not be represented as a complete compliance record.
Evaluate alternative MCP integrations by their actual resource model and permission boundary. A platform-specific MCP may be excellent for that platform’s runs while providing no connection to your BullMQ queues. Decide from the documented tools and an actual connection test, not from the presence of an MCP badge.
Common questions
Can an agent delete BullMQ jobs through Durabull MCP?
No. Job deletion, queue purging, payload edits, and raw Redis commands are not exposed by its documented MCP tools. Retry and other available writes still require appropriate scopes and can affect application behavior.
Does redaction guarantee the model never sees a secret?
No. Durabull sanitizes known sensitive fields and patterns, but arbitrary business data can contain information a pattern does not recognize. Minimize sensitive payloads and restrict access.
Does a successful retry tool call prove a job succeeded?
No. It establishes that the recovery action was accepted. Inspect the job afterward to confirm its state and application outcome.
Sources & review
Written by Durabull. Reviewed against the references below and Durabull’s implementation. Pricing examples are documented models, not measured benchmarks or vendor quotes.
Suggest a correction if a feature, price, or documented behavior has changed.
Compare the options
- Durabull vsTaskforce.shHosted dashboard by the BullMQ authors. Auto-discovers queues. Priced per Redis connection. Includes MCP.
- Durabull vsWorkbenchMIT BullMQ dashboard with Redis discovery, alerts, a desktop app, and local MCP. Discovery limits are configurable.
- Durabull vsBullpaneSelf-hosted BullMQ dashboard. Free has no login. Pro adds SSO, alerts, and MCP at $39/mo per install.
- Durabull vsInngestReplaces BullMQ. Cloud bills executions (run + each step). Official MCP inspects Inngest runs, not Redis queues.