openproject-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENPROJECT_URL | No | The base URL of the OpenProject instance, e.g., https://projects.example.com. Required unless OPENPROJECT_ENV_FILE is provided. | |
| OPENPROJECT_API_KEY | No | API key for authenticating with OpenProject. Required unless OPENPROJECT_ENV_FILE is provided. | |
| OPENPROJECT_BASE_URL | No | Alias for OPENPROJECT_URL. | |
| OPENPROJECT_ENV_FILE | No | Path to a .env file containing OPENPROJECT_* variables. Values in this file override the ambient environment. | |
| OPENPROJECT_PROJECT_ID | No | Default project ID or identifier to use when no project argument is given. | |
| OPENPROJECT_TIMEOUT_MS | No | Per-request timeout in milliseconds (default 30000). | 30000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| op_list_projectsA | List the OpenProject projects visible to the API user, with their identifiers. Paginated via pageSize and offset. |
| op_list_work_packagesA | List work packages, newest-id last. Defaults to open items only in the default project. status must be open, closed, or all — "all" includes closed items. project: "all" searches across every project even when OPENPROJECT_PROJECT_ID is set. |
| op_get_work_packageA | Fetch one work package in full detail, including custom fields, priority, version, and time aggregates. When the local hours ledger is installed, hoursLedger reports the sheet side of the task's time separately — never summed with spentTime. |
| op_create_work_packageA | Create a work package. Returns the created id. Notifications are off unless notify=true. Every change to a tracked project needs one of these before work starts. |
| op_update_work_packageA | Update a work package. lockVersion is fetched automatically, so concurrent edits fail loudly rather than silently overwriting. Notifications are off unless notify=true. |
| op_comment_work_packageA | Add a markdown comment to a work package. Notifications are off unless notify=true. |
| op_list_typesB | List the work package types available in a project, with their names. |
| op_list_time_entry_activitiesA | List the time-entry activity categories (Management, Development, …) with their ids. Needed to log time under the right category. |
| op_list_time_entriesA | List logged time. Hours are returned both as ISO-8601 duration and as a decimal, plus a total, so "how much time went into this" needs no arithmetic downstream. |
| op_log_timeA | Log time against a work package. Accepts decimal hours (1.5) or an ISO-8601 duration ("PT1H30M"). The entry is always attributed to the API key's own user — OpenProject makes that field read-only, so time cannot be logged on someone else's behalf. When the local hours ledger is installed, the result includes hoursLedger (the sheet's side for this task) so double-logging across the two ledgers is visible at the moment of the write. |
| op_list_statusesA | List every status name, so an update can name one that exists. |
| op_list_usersA | List the principals that can own a work package, with their ids. Falls back from the project's assignable users to /principals to /users, so it works on a key that cannot read /api/v3/users. source reports which list answered. |
| op_list_prioritiesA | List priority names, so a create or update can name one that exists. |
| op_list_activitiesB | List comments and activities on a work package. |
| op_list_documentsA | List documents (the Documents module), newest first. A document is a titled container for attachments with a markdown description. APIv3 has no document create or delete (UI-only), so documents are read and updated only. project: "all" searches every project even when OPENPROJECT_PROJECT_ID is set. |
| op_get_documentA | Fetch one document in full detail: title, markdown description, project, dates, and its attachments (file name, size, type, status, download URL). |
| op_update_documentA | Update a document title and/or description. The description replaces the whole markdown body. Documents carry no lockVersion, so concurrent edits are last-write-wins — unlike work packages, the API offers no optimistic locking. The "description" {"raw": …} form documented for other resources corrupts the stored text on documents (verified on 17.3, contract unchanged through 17.7); a plain string is what the UI itself sends. |
| op_add_document_attachmentA | Upload a file to a document: the API key needs the manage_documents permission in the document's project. content is the file bytes as base64. The upload is capped at the instance's attachment size limit, read from /api/v3/configuration. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools target clearly distinct resource/action pairs, and the descriptions remove most ambiguity. The only slight confusion is among op_list_time_entry_activities, op_list_time_entries, and op_list_activities, but their different subjects are clarified in the descriptions.
All tools follow a consistent op_<verb>_<noun> snake_case pattern with predictable verbs like list, get, create, update, and comment. op_log_time and op_add_document_attachment are minor stylistic variations but still fit the overall pattern.
At 18 tools, the server is slightly above the ideal 3-15 range but each tool covers a legitimate OpenProject action across projects, work packages, time tracking, and documents. The breadth is justified by the domain rather than being padded with redundant tools.
Core workflows are well covered: listing projects, CRUD-ish work package operations, commenting, time entry logging, reference data, and document read/update. Notable gaps like work-package deletion or time-entry update/delete exist, but they are secondary or documented API limitations, so agents can still complete main workflows.