Skip to main content
Glama

Get background job status

get_job_status
Read-onlyIdempotent

Check whether an asynchronous OpenProject job, such as a project copy or deletion, has finished. Poll by job id after copy_project or delete_project to read its status and outcome.

Instructions

Check whether a background job (a project copy, a scheduled deletion) has finished.

OpenProject runs copies, deletions and exports asynchronously and hands back a job id. This is the only way to learn what happened to one: call it after copy_project or delete_project and wait for a terminal state before reporting an outcome to the user.

Returns {id, status, finished, successful, message, project, result_url, notes}. status is 'in_queue' or 'in_process' while the job runs and 'success', 'failure', 'error' or 'cancelled' once it is over; finished and successful are derived from it, and successful stays null while the job runs rather than defaulting to false. A finished copy reports the new project in project and the URL it lives at in result_url.

Pitfalls: a 200 does not mean the job worked — read status. Polling is on you: wait a few seconds between calls rather than looping tightly. OpenProject drops job statuses after a while, so a 404 can mean 'long finished' as easily as 'wrong id'; confirm with get_project or list_projects. When a job fails, message is what OpenProject recorded — there is no API to retry it, so the underlying tool has to be called again deliberately.

Cross-references: copy_project and delete_project produce the job_id; get_project / list_projects verify what the job actually did.

Input Schema

NameRequiredDescriptionDefault
job_idYesBackground job id — a uuid such as '9f4c1d5e-0e2a-4f2b-9a11-2f1b3c4d5e6f'. It comes from copy_project or delete_project ('job_id' in their results), never from a project id.

Output Schema

NameRequiredDescriptionDefault
idNo
notesNo
statusNo
messageNo
projectNo
finishedYes
result_urlNo
successfulNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed26 schema fields changedv0.4.0
    • removedOutput schema / description
      Removed value: -"One background job as ``GET /job_statuses/{uuid}`` reports it."
    • removedOutput schema / properties / finished / description
      Removed value: -"True once status is terminal. False means the job is still running — poll again rather than reporting a result."
    • removedOutput schema / properties / id / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedOutput schema / properties / id / default
      Removed value: -null
    • removedOutput schema / properties / id / description
      Removed value: -"Job id (a uuid) this status belongs to."
    • addedOutput schema / properties / id / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / message / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedOutput schema / properties / message / default
      Removed value: -null
    • removedOutput schema / properties / message / description
      Removed value: -"What the job reported, e.g. why it failed."
    • addedOutput schema / properties / message / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / notes / description
      Removed value: -"Degradation markers: still running, or a reference that had to be derived."
    • changedOutput schema / properties / project / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": false,
      -    "description": "A reference to another resource. Canonical output shape.",
      -    "properties": {
      -      "id": {
      -        "anyOf": [
      -          {
      -            "type": "integer"
      -          },
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ],
      -        "default": null,
      -        "description": "Resource id."
      -      },
      -      "name": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ],
      -        "default": null,
      -        "description": "Human-readable name."
      -      }
      -    },
      -    "type": "object"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "id": {
      +        "type": [
      +          "integer",
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "name": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      }
      +    },
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / project / default
      Removed value: -null
    • removedOutput schema / properties / project / description
      Removed value: -"Project the job produced or acted on ({id, name}), when it names one — this is how a finished copy_project job hands back the new project."
    • removedOutput schema / properties / result_url / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedOutput schema / properties / result_url / default
      Removed value: -null
    • removedOutput schema / properties / result_url / description
      Removed value: -"Web URL the job stored for its result (the new project, an export download). A UI URL, not an API endpoint."
    • addedOutput schema / properties / result_url / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / status / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedOutput schema / properties / status / default
      Removed value: -null
    • removedOutput schema / properties / status / description
      Removed value: -"Job state: 'in_queue' or 'in_process' while it runs, 'success', 'failure', 'error' or 'cancelled' once it is over."
    • addedOutput schema / properties / status / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / successful / anyOf
      Removed value: -[
      -  {
      -    "type": "boolean"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedOutput schema / properties / successful / default
      Removed value: -null
    • removedOutput schema / properties / successful / description
      Removed value: -"True when the job finished successfully, false when it failed, null while it is still running. Never guess from 'finished' alone."
    • addedOutput schema / properties / successful / type
      Added value: +[
      +  "boolean",
      +  "null"
      +]
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds substantial beyond-schema context: 200 does not guarantee success, status values and null semantics, polling expectations, stale-job 404 ambiguity, and the absence of a retry API. These are exactly the behavioral traits an agent needs.

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 opening sentence states the purpose, then separate 'Returns', 'Pitfalls', and 'Cross-references' sections organize the necessary detail. Despite being longer than average, every sentence earns its place for an asynchronous status tool.

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

Completeness5/5

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

The tool has an output schema, but the description still covers terminal states, null semantics for successful, result_url/project on finished copies, stale 404 handling, and failure reporting. Nothing material is missing for correct invocation and interpretation.

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%, and the schema already explains that job_id is a uuid from copy_project or delete_project, never a project id. The description reinforces the origin of the id but does not add parameter format or validation details beyond the schema, so the 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?

States a specific verb and resource ('check whether a background job... has finished') and immediately distinguishes the tool from siblings by tying it to copy_project/delete_project job ids. The agent can tell this is the status-checking tool rather than a project or work-package operation.

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

Usage Guidelines5/5

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

Explicitly says to call it after copy_project or delete_project and wait for a terminal state. It also names alternatives for verification (get_project/list_projects) when a 404 occurs, and describes polling behavior rather than leaving it inferred.

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