LabscoMCP early access ↗
peakflamesMCP SERVER

Polarion MCP Servers

Read Polarion work items, documents and revision history from an assistant — with per-project URL aliases so one server can front several Polarion instances.

by peakflames ↗Project & Task ManagementCommunity

LABSCO SUMMARY

Aliases turn multi-instance Polarion into one deployment.

Each project or instance gets its own URL alias, so a client points at /starlight or /octopus and reaches exactly that configuration — one container, several Polarion servers, no per-team install. Two operational limits stated up front: do not run replicas, because the Polarion session is not shared across them, and the tools are read-oriented, which is the right posture for a requirements system.

What it is

Two MCP server builds for Polarion ALM: a Streamable HTTP/SSE server for shared installations and a console server for a single workstation. Both read work items and documents from Polarion — text, details, custom fields, links, document sections and revision history. Each Polarion instance you configure gets a URL alias, and clients connect to /{ProjectUrlAlias} to reach that one.

What you get

  • Work item text pulled by ID, or at a specific revision — get_text_for_workitems_by_id, get_text_for_workitem_at_revision
  • Full work item detail including status, type, assignee, custom fields and linked work items — get_details_for_workitems
  • Documents listed for the project, filtered by title or scoped to named spaces, plus the project's space list — get_documents, get_documents_by_space_names, get_space_names
  • Document structure: the sections in a document and the content of one section — get_sections_in_document, get_section_content_for_document
  • Text search for work items inside a document — search_workitems_in_document
  • The project's work item types and the custom fields available per type — list_available_workitem_types, list_available_custom_fields_for_workitem_types
  • Revision history: the revision IDs for a work item newest-first, and the content at each — get_revisions_list_for_workitem, get_revisions_content_for_workitem
  • A REST API alongside MCP, plus a health check at /api/health and API documentation at /scalar/v1

Requirements

A Polarion server and an account with appropriate permissions. The recommended deployment is Docker: pull peakflames/polarion-remote-mcp-server, mount an appsettings.json, and publish port 8080. Each entry in the PolarionProjects array carries a ProjectUrlAlias, a SessionConfig with ServerUrl, Username, Password, ProjectId and an optional TimeoutSeconds (default 60), and an optional PolarionWorkItemTypes list naming the custom fields to retrieve per type. Set POLARION_PASSWORD in the environment to override the password for every configured project and keep it out of the config file — the README recommends this over plain text. Clients connect over Streamable HTTP at http://host:8080/{ProjectUrlAlias} or SSE at the same path plus /sse; Claude Desktop reaches it through mcp-remote. REST endpoints require an X-API-Key header matching a configured consumer with the polarion:read scope, while the MCP endpoints, health checks and API docs do not. Do not run replicas — the session connection is not shared between them.

Setup effort

Follow the published steps — mkdir -p /opt/polarion-mcp-server && cd /opt/polarion-mcp-server