get_job_status

Poll a long-running MCP job by id. Returns the current status plus result or error once the worker finishes.

Purpose

Poll a long-running MCP job by id. Returns the current status plus result or error once the worker finishes.

Status values: queued → running → completed | failed.

Pair it with any tool that hands back a job_id. Today only bulk_generate_access_codes enqueues one.

Required ability

None — and deliberately so.

Ownership is the whole check here

Polling reveals nothing you did not already cause: the tool that enqueued the job enforced its own ability before queueing anything. Visibility is locked to jobs the authenticated user started, and a job belonging to somebody else returns RESOURCE_NOT_FOUND rather than a 403, so the tool cannot be used to discover that a job id exists.

This is the only tool on the server with no ability of its own. Every other one enforces the same ability its REST equivalent does.

Input schema

{
  "type": "object",
  "required": ["job_id"],
  "properties": {
    "job_id": {
      "type": "string",
      "description": "UUID of the async job to poll."
    }
  }
}

Output shape

{
  "data": {
    "job_id": "0a4e7b96-c358-4d12-9f6b-25a8013ce74f",
    "tool_name": "bulk_generate_access_codes",
    "status": "completed",
    "result": { "count": 50, "batch_unique_key": "..." },
    "error": null,
    "started_at": "2026-05-18T10:05:00Z",
    "completed_at": "2026-05-18T10:05:04Z"
  }
}

result and error are both null until the worker finishes; exactly one is populated afterwards. started_at is null while the job is still queued.

Example prompts

"Is my access-code batch done yet?"

"Poll that job until it finishes, then show me the codes."

Failure modes

AUTHENTICATION_REQUIRED — no authenticated user on the request.
RESOURCE_NOT_FOUND — unknown job_id, or the job was started by a different user.