OpenProject MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENPROJECT_URL | Yes | The URL of the OpenProject instance (e.g. https://your-openproject-instance.example.com) | |
| OPENPROJECT_API_TOKEN | Yes | OpenProject API token with required permissions | |
| OPENPROJECT_PAGE_SIZE | No | Number of items per page for paginated results | 50 |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsA | List all OpenProject projects with optional filtering by name and status |
| get_projectA | Get detailed information about a specific project |
| list_work_packagesA | List work packages with advanced filtering (tasks, bugs, features, etc.) |
| get_work_packageA | Get detailed information about a work package including description and links |
| get_work_package_activitiesA | Get activity history and updates for a work package |
| list_usersA | List all users in the OpenProject instance |
| get_userA | Get detailed user information |
| list_time_entriesA | List time entries with filtering by project, user, work package, and date range |
| get_time_entryA | Get details of a specific time entry |
| create_work_packageA | Create a new work package (Epic, User Story, Task, Bug, etc.) in a project. Use list_project_types first to find the correct type_id, and pass parent_id to nest a User Story under an Epic. |
| create_work_packages_bulkA | Create multiple work packages in one call (e.g. all the User Stories parsed from a Word document). Each item can have its own parent_id, so stories can attach to different Epics in the same call. Returns a per-item success/failure report. |
| list_project_typesA | List the work package types available in a project (e.g. Epic, User Story, Task, Bug) with their IDs, needed before creating a work package of a specific type. |
| search_work_packagesA | Search for work packages by text query with optional filters |
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 13 tools
Each tool targets a distinct resource (projects, work packages, users, time entries, types), so the set is mostly unambiguous. However, list_work_packages and search_work_packages both retrieve work packages and could be confused if an agent is not careful about filtering versus text search.
Tool names mostly follow a consistent list_/get_/create_/search_ + resource convention in snake_case. Minor deviations like create_work_packages_bulk and list_project_types are still readable and predictable.
With 13 tools, the server is well-scoped for its purpose, covering projects, work packages, users, and time entries without unnecessary bloat. Each tool has a clear role in the overall surface.
Read coverage is strong across core resources and work-package creation is supported, including bulk creation. However, there are no update or delete operations for work packages, projects, users, or time entries, leaving notable lifecycle gaps for a project-management domain.