OpenProject

OpenProject MCP Server

[PyPI] [CI] [openproject-mcp MCP server]

An MCP (Model Context Protocol) server for the OpenProject API v3. It gives Claude and any other MCP client 91 tools covering work packages, comments and relations, attachments, git/PR activity, projects, saved queries, notifications, time tracking, versions, people and memberships, meetings, news, documents, budgets and reporting — plus 4 report/workflow prompts and 3 resource templates. Built on FastMCP 4.x and httpx (HTTP/2); speaks MCP 2026-07-28 and the earlier handshake versions.

This project is aimed at the OpenProject Community edition. OpenProject's Enterprise edition now ships with its own built-in MCP integration; this server brings the same capability to self-hosted Community instances. It runs fine against any edition — it only needs the public API v3.

Design principles, all enforced in code:

• Structured everything. Every tool returns a typed model, so clients get an outputSchema and machine-readable structuredContent, not prose. Errors come back as a JSON envelope with a stable type, the upstream http_status, a message and a hint describing how to correct the call.
• Honest degradation. OpenProject instances differ by version, installed modules and permissions. Tools report what they could not see as in-band notes — a missing module yields an empty page with an explanation, never a fake success or a bare traceback.
• Safe by default. A read-only mode, admin-gated membership writes, per-group tool disabling, a confirm=true guard on every destructive tool, TLS always verified, and credentials that never appear in logs.
• Version-adaptive. Targets OpenProject 14 LTS through 17.x; API differences are detected by a lazy, cached feature probe instead of assumptions (see Supported OpenProject versions).

What it looks like

Two exchanges against a fictional "Website Relaunch" project — every id, name and date below is invented. You describe the outcome; the model picks the tools, and what comes back to it is a typed object rather than prose to re-parse.

You         What is still open in Website Relaunch and due by Friday? The checkout            bug is urgent — raise it and leave a note for whoever owns it.
  →  list_work_packages(project="website-relaunch", status_scope="open",                        due_before="2026-03-13", sort_by=[["due_date", "asc"]])
     { "items": [         { "id": 4821, "subject": "Checkout fails on expired coupon codes",           "type": {"id": 7, "name": "Bug"}, "status": {"id": 7, "name": "In progress"},           "assignee": {"id": 118, "name": "Dana Okafor"}, "due_date": "2026-03-11" },         { "id": 4830, "subject": "Move press-kit assets to the new CDN",           "type": {"id": 1, "name": "Task"}, "status": {"id": 1, "name": "New"},           "assignee": null, "due_date": "2026-03-13" }],       "pagination": {"total": 2, "page": 1, "page_size": 20, "has_more": false} }
  →  update_work_package(id=4821, priority="High")  →  add_work_package_comment(id=4821, comment="Raised to High — it blocks the                              launch checklist. Dana, can you take a look today?")
Assistant   Two open items are due by Friday. #4821 is High now and the note is on            its thread; #4830 is due Friday and still has nobody on it.

The rows above are abridged: each one also carries priority, project, start_date, percentage_done and updated_at, and the envelope keeps groups, sums and notes slots for the calls that fill them.

The prompt templates cut out the tool round trips: the server reads OpenProject itself and hands back a finished document rather than instructions to go and fetch one. It arrives prefaced with a note that the numbers are already computed and must not be recomputed or embellished.

You         /weekly_report project=website-relaunch
            # WEEKLY REPORT - AGILE SCRUM
            _Generated from live OpenProject data_            ...            ## B. EXECUTIVE SUMMARY
            **Progress against the sprint goal:** Not assessed — sprint goal and completion dates are not available
            **Currently closed work updated in the window:**            1. #4802 - Ship the new pricing page            2. #4795 - Halve the hero image payload            ...            ### Data notes
            - open/closed bucketing uses each status's isClosed flag from              GET /statuses, not status names; a status this instance renamed              or translated is still bucketed correctly

That last block is the house style: a report says which of its numbers are partial, and a tool that could not read something returns the gap as a note instead of guessing. The whole surface is in Tools and Prompts and resources.

Requirements

• Python >= 3.12
• An OpenProject instance, version 14 LTS through 17.x (any edition; aimed at Community — Enterprise ships its own MCP integration)
• An OpenProject API key: in OpenProject, go to My account → Access tokens and generate an API token

Installation

The distribution name is openproject-mcp-server. It installs two identical console scripts, openproject-mcp-server and openproject-mcp; the long form is canonical (an unrelated PyPI package also installs a bin named openproject-mcp).

Run one-shot with uv, no install step:

uvx openproject-mcp-server

Or install persistently:

uv tool install openproject-mcp-server# orpip install openproject-mcp-server

The minimal configuration is two environment variables:

export OPENPROJECT_URL=https://openproject.example.comexport OPENPROJECT_API_KEY=your-api-key

Validate the configuration without starting the server:

openproject-mcp-server --check

--check verifies the configuration and exits; it does not contact your instance. Once connected through a client, call the get_instance_info tool for a live end-to-end check. When configuration is missing or invalid, the server prints the specific problems to stderr and exits with code 2 — never a traceback.

Claude Code

claude mcp add openproject \  --env OPENPROJECT_URL=https://openproject.example.com \  --env OPENPROJECT_API_KEY=your-api-key \  -- uvx openproject-mcp-server

Claude Desktop and other MCP clients

Add to claude_desktop_config.json (or your client's equivalent mcpServers config):

{  "mcpServers": {    "openproject": {      "command": "uvx",      "args": ["openproject-mcp-server"],      "env": {        "OPENPROJECT_URL": "https://openproject.example.com",        "OPENPROJECT_API_KEY": "your-api-key"      }    }  }}

From source

git clone https://github.com/kar-thik/openproject-mcpcd openproject-mcpuv syncuv run openproject-mcp-server

Updating or rotating your API token

When a token is regenerated, revoked or invalidated (OpenProject major upgrades can do this — the symptom is every tool suddenly failing with authentication_failed / HTTP 401), generate a fresh one in OpenProject under My account → Access tokens and update it wherever your key lives:

• Shell environment (easiest to rotate). The server reads OPENPROJECT_API_KEY straight from the OS environment, so you can export it globally — e.g. in ~/.zshenv — and register the server with no --env flags at all:

  sh

  claude mcp add openproject -- uvx openproject-mcp-server

  Rotation is then: edit the export, open a fresh terminal, reconnect. The client config never contains a secret. (This does not work for GUI apps like Claude Desktop, which don't read your shell profile.)

• Claude Code with --env. The registration stores the key, so replace it:

  sh

  claude mcp remove openprojectclaude mcp add openproject \  --env OPENPROJECT_URL=https://openproject.example.com \  --env OPENPROJECT_API_KEY=new-key \  -- uvx openproject-mcp-server

  Then reconnect via /mcp (a running session keeps the old environment until it does).

• Claude Desktop and other JSON-configured clients. Edit the OPENPROJECT_API_KEY value in the client config and restart the client.

• .env file. Edit the file and restart the server.

Recent OpenProject versions allow several API tokens in parallel, so you can rotate with zero downtime: create the new token, switch your clients over, then revoke the old one.

Configuration

Configuration is entirely environment-driven. The table below is the authoritative reference: the server binds exactly these 26 names and no others. Bare, unprefixed names such as READ_TIMEOUT or API_KEY are deliberately ignored (a stray variable in your shell cannot change or break the server), as is any other unknown variable. A .env file in the server's working directory is read with the same names; real environment variables take precedence. From-source users can start from .env.example.

Secrets (OPENPROJECT_API_KEY, OPENPROJECT_OAUTH_TOKEN, OPENPROJECT_MCP_AUTH_TOKENS) are held in memory as Pydantic SecretStr values and are never written to logs; the Authorization header is redacted in every log record.

Limiting what the model can do

Four settings shrink the tool surface at startup. The tool list is then fixed for the lifetime of the process, with one exception: enable_tool_group can bring back a group hidden by the core profile, for the calling client (see below for what that means per protocol version).

• OPENPROJECT_MCP_READ_ONLY=1 serves only the 40 read tools.

• OPENPROJECT_MCP_ADMIN_TOOLS=1 reveals the three membership write tools (create_membership, update_membership, delete_membership); they are hidden by default.

• OPENPROJECT_MCP_DISABLE drops whole groups to cut prompt cost, e.g. OPENPROJECT_MCP_DISABLE=meetings,news. The valid group tags are: work_packages, wp_collaboration, attachments, git_activity, projects, queries, notifications, time_entries, versions, people, metadata, meetings, wiki, documents, budgets, news, reporting — the same tags that head each section of the tool catalog below — plus meetings_recurring, a sub-tag of meetings that drops only the six recurring-meeting tools (meetings drops them too).

• OPENPROJECT_MCP_PROFILE defaults to core (since 0.4.0), which hides the module-backed groups — meetings, news, documents, wiki, budgets, git_activity and reporting, plus the two reporting prompts — so a session starts with a smaller tool list. Set it to full to list every group from the start. When the model needs one of them it calls enable_tool_group, which restores that group and tells the client to re-read its tool list (if yours never does, set full). Who sees the restored group depends on the client's protocol version, and the result's scope field names it:

  • session — clients on the initialize handshake (MCP 2025-11-25 and earlier): that MCP session only. Over HTTP a session ends after 30 minutes idle.
  • token — MCP 2026-07-28 clients over HTTP, which have no session: every connection presenting the same bearer token. Give each user their own token in OPENPROJECT_MCP_AUTH_TOKENS if they should not share a tool list. With OPENPROJECT_MCP_INSECURE nothing identifies the client, so the call is refused; run full there (the server warns at startup).
  • process — MCP 2026-07-28 clients over stdio: the whole server process, which serves one client anyway.

  Enabled groups are forgotten after 24 hours idle. enable_tool_group never lifts READ_ONLY, the admin gate or OPENPROJECT_MCP_DISABLE; it lives in the metadata group, so disabling that group removes it.

Independent of all four, every destructive tool (the 13 permanent deletes) requires an explicit confirm=true argument before it acts.

Transports

• stdio (default) — what Claude Code, Claude Desktop and most local MCP clients use. Logs go to stderr; stdout carries only the protocol.

• Streamable HTTP — openproject-mcp-server --transport http. Binds 127.0.0.1:8000 by default; override with --host/--port or OPENPROJECT_MCP_HTTP_HOST/ OPENPROJECT_MCP_HTTP_PORT. The HTTP transport refuses to start without authentication configured: set OPENPROJECT_MCP_AUTH_TOKENS to a comma-separated list of bearer tokens, or — for local development only — set OPENPROJECT_MCP_INSECURE=1.

  With tokens configured, every HTTP request to the MCP endpoint must carry an Authorization: Bearer <token> header whose token matches one of the configured values (compared in constant time); requests with a missing, malformed or unknown token are rejected with a 401 and a WWW-Authenticate header. Multiple tokens are supported — for example one per client, so each can be revoked independently. Tokens must be ASCII, and the endpoint applies no rate limiting, so use long random values — for example python -c "import secrets; print(secrets.token_urlsafe(32))". OPENPROJECT_MCP_INSECURE=1 remains a development-only escape hatch that leaves the endpoint open without authentication.

  The server does not terminate TLS, so tokens would otherwise cross the network in plaintext: keep the default 127.0.0.1 bind, and if you must expose the HTTP transport beyond localhost, put it behind a TLS-terminating reverse proxy (for example nginx or Caddy).

  One upstream identity. Bearer tokens decide who may reach the endpoint, not who they are in OpenProject: the server holds a single OPENPROJECT_API_KEY (or OAuth token), and every HTTP client acts as that OpenProject user and shares its metadata cache. Deploy it for clients you would trust with that account, and issue a dedicated, least-privileged OpenProject user for it.

  File tools touch the server's disk. upload_attachment, create_work_package (attachment_paths) and download_attachment read and write paths on the machine running the server. Over HTTP they are off until you confine them: upload_attachment and attachment_paths need OPENPROJECT_MCP_UPLOAD_ROOT, download_attachment needs OPENPROJECT_MCP_DOWNLOAD_ROOT. Until then the tool is hidden (and attachment_paths is refused), and the server names the missing variable in a startup warning.

Tools

91 tools: 42 read, 46 write and 3 admin-gated writes. The admin tools stay hidden unless OPENPROJECT_MCP_ADMIN_TOOLS=1; the 13 destructive tools additionally require confirm=true on every call. Each section heading names the group tag accepted by OPENPROJECT_MCP_DISABLE.

Work packages (work_packages)

Batch workflow: call bulk_update_work_packages(updates=[{"id": 4821, "changes": {"target_versions": [3, 4]}}]) to preview. Review the returned changes, then repeat with dry_run=false and each item's returned lock_version included in updates. Any preflight error prevents the whole batch from writing. A later conflict can produce partial success; inspect every item and never replay successful updates. unknown means the write may have committed before the response was lost.

Comments, relations, watchers, reminders (wp_collaboration)

Attachments and file links (attachments)

Git and pull requests (git_activity)

Projects (projects)

Saved queries (queries)

Notifications (notifications)

Time tracking (time_entries)

Versions and sprints (versions)

People and memberships (people)

The three membership write tools require OPENPROJECT_MCP_ADMIN_TOOLS=1 (and an OpenProject account with the Manage members permission).

Instance metadata and schemas (metadata)

Meetings (meetings)

The six recurring-meeting tools also carry the meetings_recurring tag, so OPENPROJECT_MCP_DISABLE=meetings_recurring drops just them (they need OpenProject 17.4+).

Wiki (wiki)

Documents (documents)

Budgets (budgets)

News (news)

Reporting (reporting)

Prompts and resources

Report data uses closed_updated for currently closed work updated in the requested window. This replaces the former closed field in v0.3.0. It does not establish when work was completed; sprint health remains unassessed without supporting data.

Four prompt templates render live OpenProject data into ready-to-use briefings:

• weekly_report — a weekly status report for one project: currently closed and updated / in progress / planned, hours and impediments.
• daily_standup — today's standup for one project: yesterday's movement, what is due today, and what is blocked.
• triage_inbox — groups your unread notifications by reason and suggests actions.
• groom_backlog — sweeps a project's open backlog for unassigned, stale and unestimated work.

Three resource templates expose OpenProject objects at stable URIs:

• openproject://work_package/{id} — one work package as JSON.
• openproject://project/{identifier} — one project as JSON (identifier slug or numeric id).
• openproject://attachment/{id} — the attachment's bytes with the detected MIME type, up to OPENPROJECT_MCP_MAX_INLINE_MB.

Clients that support argument completion get suggestions while typing: project identifiers for the project argument of weekly_report, daily_standup and groom_backlog and for the project resource, and the available locales for weekly_report.

Supported OpenProject versions

The server targets OpenProject 14 LTS through 17.x. Instead of assuming one API dialect, it probes the instance lazily on first need and caches the result for an hour. The version-dependent surfaces:

• Target versions: work-package details expose target_versions on every supported instance. Create/update accept a list of version ids ([] clears); the schema selects targetVersions on 17.8+ or a single legacy version. The old version argument remains a single-value alias; do not pass both. On reads it is null for multiple assignments.
• Internal (private) comments need OpenProject >= 16. Older servers silently ignore the internal flag, so below 16 the server refuses with a clear error rather than posting a comment publicly that you asked to keep internal.
• Emoji reactions (toggle_comment_reaction) need OpenProject >= 16; detected from the version, tolerant of a 404 at call time.
• Project favorites (set_project_favorite) need OpenProject >= 17; same tolerance.
• Time-entry filters: the work-package filter is probed (entityId, falling back to the pre-15.x workPackage spelling).
• Permission contexts (list_permissions): the context prefix is probed (p{id}, falling back to the w{id} spelling introduced in 17.2).
• Meetings time filter: OpenProject 17.6 changed the wire dialect; list_meetings discovers which spelling the instance accepts and caches it.
• Story points need the Backlogs module and a type Backlogs treats as a story. 17.x refuses story_points otherwise; 14.x accepts the write and silently drops the value, so the result carries a note saying it was not saved (bulk previews warn before writing).

Features that depend on optional instance modules (meetings, news, documents, budgets, wiki, backlogs, GitHub/GitLab integration, external storages) degrade honestly when the module is absent: list tools return an empty page with an in-band note naming the missing module, and detail tools return a structured error explaining both possible readings of the 404.

Security

• The API key and OAuth token are held as SecretStr and never logged; Authorization and cookie headers are redacted from every log record. Request/response bodies are only logged at DEBUG level with OPENPROJECT_MCP_LOG_BODIES=1, for development.
• The Authorization header is stripped whenever a redirect leaves the OpenProject origin — attachment downloads redirect to presigned object-storage URLs, and the credential must not travel there.
• TLS is always verified. Private CAs are supported via OPENPROJECT_MCP_CA_BUNDLE; an insecure-TLS switch deliberately does not exist.
• Attachment downloads respect OpenProject's virus scanner: quarantined files are never fetched and produce a structured attachment_quarantined error. Downloads are capped by OPENPROJECT_MCP_MAX_DOWNLOAD_MB, stored under sanitized file names (directory separators and traversal sequences are neutralized), and reported with a SHA-256 of the bytes.
• Destructive tools require confirm=true and are annotated so clients can ask the user first.
• The HTTP transport refuses to start without OPENPROJECT_MCP_AUTH_TOKENS configured and verifies the Authorization: Bearer header on every request — missing or invalid tokens are rejected with a 401, and token comparison is constant-time. The server does not terminate TLS: keep the default 127.0.0.1 bind, and put a TLS-terminating reverse proxy in front if the port must be reachable from anywhere else (see Transports). All HTTP clients share the server's one OpenProject identity; confine the file tools with OPENPROJECT_MCP_UPLOAD_ROOT / OPENPROJECT_MCP_DOWNLOAD_ROOT.
• Downloads are created exclusively (never overwriting an existing file, even under concurrent downloads of the same name), and a failed or cancelled transfer removes only the file it created.

Troubleshooting

When reporting an issue, please include your OpenProject version, the output of openproject-mcp-server --version, and the output of openproject-mcp-server --check.

Development

git clone https://github.com/kar-thik/openproject-mcpcd openproject-mcpuv sync --group devuv run pytest              # entire suite runs offline (respx-mocked HTTP), no instance neededuv run ruff check .uv run ruff format --check .uv run pyright             # strict mode

The default suite stays offline. Opt-in compatibility checks run against fresh official OpenProject 14.6, 15.5, 16.6 and 17.8 containers in the Compatibility workflow (including both single- and multiple-version modes on 17.8). To run one locally with Docker running:

uv run python scripts/live_smoke.py --image openproject/openproject:17.8.0

The harness seeds a private project, temporary users, custom fields and versions; it tests through MCP, then removes the container and its volumes. Existing instances and credentials are not used. Direct pytest runs skip these tests unless --live-openproject is supplied with a disposable fixture file. The full technical specification lives in SPEC.md.

Releasing is documented in CONTRIBUTING.md.

License and trademark

MIT — see LICENSE.

This is a community project. It is not affiliated with, endorsed by, or supported by OpenProject GmbH. "OpenProject" is a trademark of OpenProject GmbH and is used here only to indicate interoperability.