Skip to main content
Glama
Sign In
OpenProject CE MCP

OpenProject CE MCP

by jtauschl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_status

Read-onlyIdempotent

Retrieve a single work package status by ID to check the current state of a specific work package in OpenProject.

Instructions

Get a single work package status by id.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "status_id": "<status_id>"
    },
    "name": "get_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
status_idYes

Output Schema

NameRequiredDescriptionDefault
idYes
nameYes
colorYes
positionYes
is_closedYes
is_defaultYes
is_readonlyNo
default_done_ratioNo
excluded_from_totalsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.7
    • addedInput schema / additionalProperties
      Added value: +false
    • removedOutput schema / properties / url
      Removed value: -{
-  "title": "Url",
-  "type": "string"
-}
    • changedOutput schema / required
      Previous value: -[
-  "id",
-  "name",
-  "is_default",
-  "is_closed",
-  "color",
-  "position",
-  "url"
-]New value: +[
+  "id",
+  "name",
+  "is_default",
+  "is_closed",
+  "color",
+  "position"
+]
  2. Changed3 schema fields changedv0.3.0
    • addedOutput schema / properties / default_done_ratio
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Default Done Ratio"
+}
    • addedOutput schema / properties / excluded_from_totals
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Excluded From Totals"
+}
    • addedOutput schema / properties / is_readonly
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Is Readonly"
+}
  3. First observedv0.2.2

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds essentially no behavioral context beyond restating that it retrieves a single status, and does not describe error behavior, permissions, or lookup scope.

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?

A single, front-loaded sentence that identifies the operation and the key input. There is no filler or redundancy.

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

Completeness3/5

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

For a simple single-record read tool with annotations and an output schema, the description is enough to identify the operation. However, it leaves gaps around parameter sourcing and how it relates to list_statuses, so it is only adequate rather than complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only says 'by id', which minimally maps to status_id but does not explain the identifier format, where to obtain it, or whether invalid ids return errors.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: get a single work package status by id. This distinguishes it from list-style siblings such as list_statuses, but it does not explicitly name alternatives or clarify how it differs from related getters like get_work_package or get_job_status.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as list_statuses or the work package tools. The description implies retrieval by id, but provides no exclusions, prerequisites, or alternative-routing advice.

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

Deploy Server

Other Tools