mcp-queue-doctor
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DATABASE_URL | No | Postgres connection string. Alternative to QUEUE_DOCTOR_DATABASE_URL. | |
| QUEUE_DOCTOR_SCHEMA | No | Schema the queue was installed into. Defaults to the backend's default schema. | |
| QUEUE_DOCTOR_BACKEND | No | Backend to use: 'pgboss' or 'graphile'. | pgboss |
| QUEUE_DOCTOR_MAX_ROWS | No | Row cap per query (1–10000). | 500 |
| QUEUE_DOCTOR_LOG_LEVEL | No | Log level: debug/info/warn/error/silent (stderr). | info |
| QUEUE_DOCTOR_AXIOM_TOKEN | No | Read-capable Axiom token for log correlation (optional). | |
| QUEUE_DOCTOR_AXIOM_ORG_ID | No | Axiom organization ID for log correlation (optional). | |
| QUEUE_DOCTOR_DATABASE_URL | No | Postgres connection string. Required unless using the HTTP SQL transport. Alternative alias: DATABASE_URL. | |
| QUEUE_DOCTOR_HTTP_SQL_URL | No | URL of a read-only SQL endpoint to query through instead of connecting directly. Must be used together with QUEUE_DOCTOR_HTTP_SQL_TOKEN. | |
| QUEUE_DOCTOR_AXIOM_DATASET | No | Axiom dataset name for log correlation (optional). | |
| QUEUE_DOCTOR_HTTP_SQL_TOKEN | No | Bearer token for the HTTP SQL endpoint. | |
| QUEUE_DOCTOR_AXIOM_QUEUE_FIELD | No | Field in Axiom logs carrying the queue name (optional). | |
| QUEUE_DOCTOR_STATEMENT_TIMEOUT_MS | No | Per-query timeout in milliseconds (100–120000). | 5000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| server_infoA | Report queue-doctor's configuration, database connectivity, and the detected pg-boss schema — including which dialect matched, whether that schema version has been verified, and any reduced capabilities. Call this first whenever another tool returns an unexpected or empty result. |
| queue_overviewA | Per-queue health snapshot: job counts by state, jobs stuck active, completions and failures in the window, and each queue's configured expiry, retention and retry limit. Failed counts are reported both within the window and all-time, because the two disagreeing is itself diagnostic. |
| failed_jobsA | Jobs that failed within the window, newest first, with the error message pulled from each job's output. Bounded on when the job finished — not on the row merely being in the failed state — so results reflect what broke recently rather than everything still inside the queue's retention period. |
| stuck_jobsB | Jobs that have been active longer than a threshold, with age, configured expiry, and — where the schema supports heartbeats — how long since the worker last checked in. A stale heartbeat distinguishes an abandoned job from a merely slow one. |
| schedule_statusA | Every cron schedule pg-boss has registered, with its expression, timezone, last observed firing, and the previous and next firings the expression implies. Expectations are derived from the schedule table itself, so no configuration is needed. |
| missed_schedulesA | Only the cron schedules whose most recent firing is older than their expression implies. Schedules registered more recently than their last expected tick are excluded, since they cannot have missed it. |
| job_detailA | One job's full record: state, timestamps, retry counters, configured expiry and dead-letter queue, computed duration, and its payload and output. Use this to read the actual error behind a failure surfaced by another tool. |
| diagnoseA | Run the whole diagnosis catalog and return ranked findings — retry storms, expiry overruns, stuck or abandoned workers, missed schedules, duplicate cron registration, retention-window confusion, and idle queues. Each finding carries the evidence it was drawn from and recovery steps ordered safest-first. This is the tool to reach for when the question is "what is wrong?". |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a clearly distinct concern: aggregate diagnosis, server/schema info, queue-level health, failed jobs, stuck jobs, schedule listings, missed schedules, and individual job records. The only near-overlap (schedule_status vs missed_schedules) is resolved by one being the full set and the other a filtered diagnostic view.
Tool names are uniformly lowercase snake_case and mostly follow a descriptive noun-phrase pattern like failed_jobs, queue_overview, and schedule_status. The single verb-only name diagnose breaks the pattern slightly, but it is still consistent with the diagnostic domain and not confusing.
Eight tools is a well-scoped size for a queue diagnosis server. Each tool covers a distinct diagnostic need without redundancy or filler, and the count is squarely in the comfortable mid-range.
The tool surface covers the full diagnostic workflow: server health, per-queue health, failed/stuck jobs, schedule monitoring, missed schedule detection, and deep-dive job details. There are no obvious dead ends; the diagnose tool ties the narrower tools together, and job_detail lets an agent follow up on any surfaced error.