Polarion ALM × your AI assistant

Your Polarion work.
One conversation away.

Find the right requirements. Review a document.
Prepare your next test run. Just ask your AI.

An open-source MCP server connecting Polarion to Claude, ChatGPT,
Copilot, Gemini and the tools you already use.

Connect your assistant Run with Docker

From a question to the right action

What the connector
does for you.

Your assistant chooses the tools. The server turns each call into a Polarion REST request. You keep the project context and control the changes.

The assistant summarizes returned data and proposes changes. Every write can be previewed first: the server shows the exact request without sending it. Approval is a workflow you set in your client; the server does not add a universal approval dialog.

Complete REST coverage

Every Polarion REST operation is a tool.

All 284 operations of the current Polarion REST API definition, generated from its OpenAPI spec and live-tested on Polarion 2506 and 2606. Your configuration can expose a smaller set.

70 operations

Work items

Find requirements, triage defects and prepare field updates.

68 operations

Test management

Prepare test runs and record the results your team supplies.

25 operations

Plans & collections

Check release scope and keep document collections together.

33 operations

Documents

Read LiveDocs, inspect their parts and work with attachments.

23 operations

Pages

Read and maintain supported project and repository pages.

18 operations

Enumerations

Discover the allowed values for your project’s fields.

24 operations

Projects & people

Find accessible projects, users and configuration context.

23 operations

Admin & jobs

Inspect metadata and manage available background jobs.

Less searching. More context.

A day with Polarion MCP.

Five conversations you could have with your assistant. These are illustrative workflows and results, using real tools. Your project types, link roles and permissions determine what works.

Start with the blockers.

You

Which open defects could block Release 2.4? Group them by severity and show who owns the next step.

Tools called by your assistant

  1. getWorkItems

    Query defects in the chosen project and release; page through the results.

  2. getWorkItem

    Read each candidate’s severity, owner and current status.

Assistant · illustrative result

Example: 8 open defects, 2 critical, 3 without an owner. A short triage list with item IDs, links and missing information to check.

Read-only review. Ask for approval before proposing any reassignment or status change.

Turn a vague requirement into a proposal.

You

Review the requirements in the Brake Control LiveDoc. Rewrite REQ-17 so its acceptance criteria are measurable. Preview the change first.

Tools called by your assistant

  1. getDocument

    Read the selected document’s metadata.

  2. getDocumentParts

    Locate the referenced work items in the document.

  3. getWorkItem

    Read REQ-17 and its current description.

  4. patchWorkItem

    dry_run: true · preview the proposed description update.

Assistant · illustrative result

Example: a proposed REQ-17 description, the assumptions behind the rewrite, and a preview of the PATCH request. Nothing has been saved.

You review the proposal. Only after approval does the assistant repeat the update without dry_run. This edits the requirement, not arbitrary LiveDoc body text.

From requirements to a test record.

You

Draft test cases for these requirements and prepare a test run. After I execute them, record the results I provide. Preview all writes first.

Tools called by your assistant

  1. getWorkItems

    Read the selected requirements and check existing test cases first.

  2. postWorkItems

    dry_run: true · draft test case items using the project’s configured types.

  3. postTestRuns

    dry_run: true · preview the new test run.

  4. postTestRecords

    After execution and approval, record the supplied outcomes; preview first.

Assistant · illustrative result

Example: 4 draft test cases and a run proposal. After you execute the tests and provide outcomes, the assistant can record those results in Polarion.

Approve each write after its preview. The connector records results; it does not execute your product tests or infer a pass.

Bring evidence to the status meeting.

You

Summarize the Release 2.4 plan: unfinished work, owners, open defects and the latest test runs. Flag anything the data cannot answer.

Tools called by your assistant

  1. getPlan

    Read the chosen plan and its scheduled item relationships.

  2. getWorkItems

    Read the scheduled items and release defects.

  3. getTestRuns

    Read matching run status and available result fields.

Assistant · illustrative result

Example: 12 unfinished items, 2 blocking defects and 1 unfinished run, with source IDs and a list of missing data. A draft meeting update you can check.

Read-only summary. You decide whether the release is ready; the assistant does not approve or close it.

Find the missing links before the review.

You

For the requirements in this release, find those without a verifies link to a test case. Check existing items before proposing new tests.

Tools called by your assistant

  1. getWorkItems

    Fetch the agreed requirement scope and any candidate test cases.

  2. getLinkedWorkItems

    Inspect each requirement’s links and the project’s link direction.

Assistant · illustrative result

Example: 6 requirements without the expected test link. Existing candidate tests are listed separately from requirements that may need a new test.

Read-only gap list. Review the project’s link roles and scope before approving any new item or link.

Start small: scope one project, inspect existing items, preview writes, then verify what changed. The assistant still needs your judgment.

Get connected

Your assistant. Your setup.

Choose how the server runs, then connect your client. Pick a client below to see its supported paths and best default. You need a REST-enabled Polarion instance and a PAT.

On your computer? npm / npx starts with your client, using Node.js 22+.

Setting up a team? Docker hosts the server. Cloud connectors need HTTPS and OAuth.

Already hosted? Choose Remote URL. Get the endpoint from your administrator.

AI providers

Claude

Desktop, web and developer tools

ChatGPT / OpenAI

ChatGPT, custom GPTs and Codex

Microsoft

Team agents and your editor

Google

Gemini Enterprise and Gemini CLI

Other / Custom

Docker, HTTP, REST/OpenAPI, n8n or any other client

Tools / IDEs

Your development workspace

Use the client you already work in.

npm / npx

Claude Desktop

1. How do you run the server?

Claude Desktop · Local MCP configuration

  1. Open the Claude menu in the system menu bar, then Settings... > Developer.
  2. Click Edit Config to open claude_desktop_config.json.
  3. Add the polarion entry inside mcpServers, or paste the whole snippet.
  4. Replace YOUR-POLARION and YOUR_POLARION_PAT, then save the file.
  5. Quit Claude Desktop completely and start it again.
  6. In a new chat, check that polarion is listed under Connectors.
json · client configuration
{
  "mcpServers": {
    "polarion": {
      "command": "npx",
      "args": ["-y", "polarion-mcp"],
      "env": {
        "API_BASE_URL": "https://YOUR-POLARION/polarion/rest/v1",
        "BEARER_TOKEN": "YOUR_POLARION_PAT"
      }
    }
  }
}

Node.js 22+ runs the published npm package on your computer. Replace the URL and PAT locally; keep credentials out of Git.

Client documentation ↗Questions ↓

No public Polarion relay. Host the server yourself or use your team’s URL. The separate REST wrapper serves OpenAPI clients with a deployment PAT and HTTP_API_KEY.

A few things before you go

Questions? Start here.

Setup, permissions and updates, in one place.

Which setup do I need?

Desktop or coding client: npm / npx (your client starts the server). Shared team server: Docker. claude.ai or ChatGPT connector: a public HTTPS server with OAuth, so Docker, or Remote URL if your team runs one. Custom GPT Actions use the REST wrapper.

How do I create a Polarion personal access token (PAT)?

Polarion user page > Personal Access Token > name and expiry > Create Token. Copy it at once, it is shown only once. If the page says token generation is not allowed, your administrator must enable com.siemens.polarion.rest.security.restApiToken.enabled=true.

Is my data safe? Which permissions apply?

Polarion enforces the permissions of the token owner. Remote mode uses each caller's own token and the server stores none. Tool results go to your AI provider, so your organization's data policies apply.

Can I limit the server to read-only?

Yes: set MCP_READ_ONLY=1 and restart. Only read tools are exposed. In write-enabled sessions every write tool can preview with dry_run: true.

It says 401 "Polarion did not accept this token".

The token was cut off, has expired, or belongs to another Polarion. Run the token test from Before you start and create a new token.

It says 403 "Polarion denied access".

The token is known but refused. Check: REST enabled (com.siemens.polarion.rest.enabled=true), your user has a license and project access, and no proxy blocks /polarion/rest or the Authorization header.

My AI client says "Disconnected" or "Failed to connect".

npm: run npx -y polarion-mcp in a terminal with the same values to see the real error (Node older than 22 and JSON typos are common). Docker or remote: open https://YOUR-SERVER/health, then read docker logs polarion-mcp.

The connector login in claude.ai or ChatGPT fails or loops.

Check MCP_PUBLIC_URL (exact https address, no path), the padlock, that the redirect preset or callback is allowed (MCP_ALLOWED_REDIRECT_PRESETS=claude; the log says redirect_uri rejected), and that MCP_TOKEN_SECRET did not change.

More answers on GitHub ↗