Skip to main content
Glama
Sign In
OpenProject CE MCP

OpenProject CE MCP

by jtauschl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_category

Read-onlyIdempotent

Retrieve a single category by ID and optionally cross-check it against a project to verify the correct association.

Instructions

Get a single category by id.

project is optional: when given, it's cross-checked against the category's real project and a mismatch raises a not-found error, rather than being the sole source of authorization.

Input Schema

NameRequiredDescriptionDefault
projectNoProject identifier, id, or name; a unique part of a name or identifier also matches.
category_idYes

Output Schema

NameRequiredDescriptionDefault
idYes
nameYes
projectYes
project_idYes
default_assigneeNo
default_assignee_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.4
  2. Removedv0.4.0
  3. Changed2 schema fields changedv0.3.8
    • removedOutput schema / properties / is_default
      Removed value: -{
-  "title": "Is Default",
-  "type": "boolean"
-}
    • changedOutput schema / required
      Previous value: -[
-  "id",
-  "name",
-  "project_id",
-  "project",
-  "is_default"
-]New value: +[
+  "id",
+  "name",
+  "project_id",
+  "project"
+]
  4. 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",
-  "project_id",
-  "project",
-  "is_default",
-  "url"
-]New value: +[
+  "id",
+  "name",
+  "project_id",
+  "project",
+  "is_default"
+]
  5. Addedv0.3.3
  6. Removedv0.3.0
  7. First observedv0.2.2

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral information: the optional project is validated against the category's real project and a mismatch yields a not-found error rather than acting as an authorization scope. That is non-obvious error semantics an agent cannot get from the structured fields.

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?

Two short sentences, front-loaded with the core action, followed by the one subtle parameter rule. No filler or repetition of schema/annotation content.

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

Completeness4/5

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

With an output schema present there is no need to describe return values, and annotations cover the read-only/idempotent profile. The description covers the one genuinely tricky element (project validation). Minor gap: it doesn't state what happens for a nonexistent category_id or a permission failure, but the essential call-shaping information is present.

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

Parameters4/5

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

Schema coverage is 50% — project has a description, category_id does not. The description compensates by explaining the exact semantics of the under-documented project parameter: it is a cross-check, not an authorization source, and mismatches surface as not-found. This is meaning beyond the schema's 'id, or name' note.

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?

States a specific verb and resource: 'Get a single category by id.' The word 'single' implicitly distinguishes it from list_categories, but the sibling is never named, so the differentiation is inferential rather than explicit.

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

Usage Guidelines3/5

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

Usage is only implied by 'single category by id' — an agent can infer this is a fetch-one-vs-list-many tool, but the description never says when to prefer it over list_categories or what happens when the id doesn't exist (aside from the project-mismatch case).

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