Skip to main content
Glama
kar-thik

OpenProject CE MCP Server

by kar-thik
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Search work packages

search_work_packages
Read-onlyIdempotent

Find work packages by subject, ID, or description when you don't know their ticket numbers. Use quick mode to match names or fulltext mode to search descriptions and comments, then feed returned IDs into related tools.

Instructions

Find work packages by text when you do not know their ids.

Use this first whenever a user names a ticket instead of numbering it, then feed the returned id into get_work_package, update_work_package or list_work_packages.

Returns the standard list envelope: compact rows (id, subject, type, status, priority, assignee, project, dates, progress) plus pagination with total/page/page_size/has_more.

Pitfalls: search filters, it does not rank, so a broad query returns a lot — narrow it with project_id, or switch to list_work_packages when you want structured filters (assignee, due date, version) rather than text. Attachment-content matching in 'fulltext' mode depends on instance database configuration and is reported honestly in notes.

For structured filtering use list_work_packages; for one work package's full detail (description, custom fields, children) use get_work_package.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'quick' (default) matches subject, id, project name and type/status names — this is what the OpenProject header search runs and the right choice for 'find the ticket called X'. 'fulltext' additionally matches description text, comments and searchable custom fields; use it for 'which ticket mentions Y'.quick
pageNo1-based page number.
queryYesFree text to look for. In 'quick' mode a bare number also matches a work package id, so '1234' finds #1234.
page_sizeNoResults per page (max 100).
project_idNoRestrict the search to one project: numeric id or the project identifier (the slug in the OpenProject URL). Both come from list_projects. Omit to search every project the user can see.
status_scopeNoWhich statuses to search. Defaults to 'all' because finding closed items is usually the point of a search; pass 'open' to hide finished work. An explicit status filter is always sent, so the server's implicit open-only default never applies.all

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sumsNoPresent only when show_sums was requested.
itemsNoThe page of results.
notesNoDegradation markers: capped aggregations, unavailable modules, …
groupsNoPresent only when group_by was requested.
paginationYesTotal/page/page_size/has_more.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Discloses that search filters and does not rank, recommends narrowing with project_id, and warns that fulltext attachment matching depends on instance database configuration. It also explains the status_scope sentinel behavior, which is not visible in annotations.

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?

Four well-organized sentences front-load the purpose and usage, then cover return format, pitfalls, and alternatives without redundancy. Every sentence earns its place.

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?

Covers when to use, what it returns, how to chain results, key caveats, and sibling tool differentiation. The output schema exists, so detailed return structure is not needed in the description.

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 coverage is 100% and the schema already includes rich descriptions for every parameter. The description's guidance to narrow with project_id and the status_scope behavior is already present in the schema, so the description adds little beyond it.

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?

The opening line 'Find work packages by text when you do not know their ids' clearly states the verb, resource, and the trigger condition, distinguishing it from list_work_packages (structured filters) and get_work_package (by id).

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 instructs to 'Use this first whenever a user names a ticket instead of numbering it,' and names the follow-up tools to feed the id into. It also contrasts with list_work_packages for structured filters and get_work_package for full detail.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kar-thik/openproject-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server