Polarion MCP

Overview Schema Source Related Servers Discussions Admin

read_work_item

Read-only

Retrieve a Polarion work item by project and ID, returning its content rendered as Markdown for easy reading and analysis.

Instructions

Read one work item with its body rendered as Markdown.

Synthesis output — collapses Polarion anchors; NEVER feed it to update_work_items. Edits round-trip via get_work_item(include_description_html=True) instead.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`project_id`	Yes	Polarion project ID.
`work_item_id`	Yes	Work item ID (e.g. 'MCPT-001').

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`type`	Yes
`title`	Yes
`status`	Yes
`created`	No
`updated`	No
`priority`	No
`severity`	No
`space_id`	No
`author_id`	No
`hyperlinks`	No
`project_id`	Yes
`resolution`	No
`author_name`	No
`description`	No
`assignee_ids`	No
`custom_fields`	No
`document_name`	No
`assignee_names`	No
`outline_number`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Jul 22, 2026
Removedv2.0.0Jul 22, 2026
Changed1 schema field changedv1.4.1Jul 7, 2026
- addedOutput schema / properties / hyperlinks / items / additionalProperties
```
Added value: +false
```
Changed1 schema field changedv1.4.0Jun 26, 2026
- changedInput schema / properties / work_item_id / description
```
Previous value: -"Work Item ID (e.g. 'MCPT-001')."New value: +"Work item ID (e.g. 'MCPT-001')."
```

Changed22 schema fields changedv1.1.0Jun 9, 2026

changedOutput schema / description

Previous value: -"LLM-friendly work-item view returned by ``read_work_item``.\n\nMirrors ``WorkItemDetail`` but exposes ``description`` as Markdown\n(converted from Polarion HTML) instead of the raw ``description_html``.\nRead-only synthesis: the Markdown body cannot be fed back to\n``update_work_item`` (the converter collapses Polarion-specific\nmarkup). For round-trip editing, use\n``get_work_item(include_description_html=True)`` paired with\n``update_work_item(description_html=...)``.\n\n``custom_fields`` keeps rich-text values as\n``{'type': 'text/html', 'value': '<...>'}`` dicts so this dict alone\ncan be copied back into ``update_work_item(custom_fields=...)``."New value: +"LLM-friendly work-item view returned by ``read_work_item``."

removedOutput schema / properties / assignee_ids / description

Removed value: -"Short user IDs of assignees; empty list when unassigned."

removedOutput schema / properties / author_id / description

Removed value: -"Short user ID of the author; empty when unreported."

removedOutput schema / properties / created / description

Removed value: -"ISO-8601 creation timestamp; empty when unreported."

removedOutput schema / properties / custom_fields / description

Removed value: -"Project-defined custom fields keyed by field ID."

removedOutput schema / properties / description / description

Removed value: -"Body as Markdown; read-only — do NOT feed to update_work_item."

removedOutput schema / properties / document_name / description

Removed value: -"Containing document name; empty when free-floating."

removedOutput schema / properties / hyperlinks / description

Removed value: -"External hyperlinks attached to this work item."

removedOutput schema / properties / hyperlinks / items / properties / role / description
```
Removed value: -"Hyperlink role id (e.g. 'ref_ext')."
```
removedOutput schema / properties / hyperlinks / items / properties / title / description
```
Removed value: -"Human-readable link title; empty when unset."
```
removedOutput schema / properties / hyperlinks / items / properties / uri / description
```
Removed value: -"Target URI of the hyperlink."
```

removedOutput schema / properties / id / description

Removed value: -"Work Item ID (e.g. 'MCPT-001')."

removedOutput schema / properties / outline_number / description

Removed value: -"Hierarchical position (e.g. '1.2.3'); empty outside a document."

removedOutput schema / properties / priority / description

Removed value: -"Priority value as a string (e.g. '90.0'); empty when unset."

removedOutput schema / properties / project_id / description
```
Removed value: -"Project that contains this work item."
```

removedOutput schema / properties / resolution / description

Removed value: -"Resolution outcome (e.g. 'fixed'); empty when unresolved."

removedOutput schema / properties / severity / description

Removed value: -"Severity classification (e.g. 'critical'); empty for non-defects."

removedOutput schema / properties / space_id / description

Removed value: -"Containing document's space; empty when free-floating."

removedOutput schema / properties / status / description

Removed value: -"Workflow status (e.g. 'draft', 'approved')."

removedOutput schema / properties / title / description
```
Removed value: -"Work Item title."
```

removedOutput schema / properties / type / description

Removed value: -"Work Item type (e.g. 'requirement', 'testCase')."

removedOutput schema / properties / updated / description

Removed value: -"ISO-8601 last-modified timestamp; empty when unreported."

First observedv0.9.0May 28, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds value beyond the readOnlyHint annotation by disclosing that the output collapses Polarion anchors and that the body is rendered as Markdown. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that are front-loaded with the core purpose, followed by critical usage warnings. Every sentence serves a purpose with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and the readOnlyHint annotation, the description adequately covers the tool's behavior and return format. The warning about synthesis output completes the behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with clear parameter descriptions. The tool description does not add further parameter details, but the schema already suffices. Baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read one work item with its body rendered as Markdown.' It identifies the specific verb ('read') and resource ('work item'), and distinguishes from siblings like 'get_work_item' by noting the Markdown rendering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly warns against feeding the output to update_work_items and provides a clear alternative for edits: 'get_work_item(include_description_html=True)'. This gives both when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server