Polarion MCP

Overview Schema Source Related Servers Discussions Admin

read_document

Read-only

Render a Polarion document as flowing Markdown to read its full content, including headings, work-item descriptions, and prose. Get a complete view of the document body.

Instructions

Render a document end-to-end as flowing Markdown — THE way to read a body.

Interleaves headings, work-item descriptions, and prose. Synthesis output: NEVER feed it to update_document — round-trip via get_document(include_home_page_content_html=True). For metadata-only extraction use list_work_items with SQL.

Input Schema

TableJSON Schema

Name	Required	Description
`space_id`	Yes	Space ID ('_default' = default space).
`page_size`	No
`project_id`	Yes	Polarion project ID.
`page_number`	No
`document_name`	Yes	Document name within space_id.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`page`	Yes
`content`	Yes
`has_more`	No
`page_size`	Yes
`part_count`	Yes
`total_parts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.4.0Jun 26, 2026

changedInput schema / properties / document_name / description

Previous value: -"Document name within the space."New value: +"Document name within space_id."

changedInput schema / properties / space_id / description

Previous value: -"Space ID containing the document."New value: +"Space ID ('_default' = default space)."

Changed9 schema fields changedv1.1.0Jun 9, 2026

removedInput schema / properties / page_number / description

Removed value: -"Page number to retrieve (1-based, default 1)."

removedInput schema / properties / page_size / description

Removed value: -"Number of parts per page (1-100, default 100)."

changedOutput schema / description

Previous value: -"Rendered Markdown view of one page of document parts.\n\nReturned by ``read_document``. Interleaves heading titles, embedded\nwork-item descriptions, and inline prose from a single page of\n``read_document_parts`` into a flowing Markdown stream suitable for\nend-to-end reading by an LLM.\n\nThe output is read-only synthesis: it cannot be fed back to any\nwrite tool because no update path accepts this shape. For round-trip\nediting of the document body, fetch the raw source via\n``get_document(include_homepage_content_html=True)`` instead.\n\n``part_count`` reflects parts consumed from ``read_document_parts``\non this page — including widget placeholders that produce no output\n— so use it for pagination accounting, not chunk count."New value: +"Rendered Markdown view of one page of document parts (``read_document``)."

removedOutput schema / properties / content / description
```
Removed value: -"Rendered Markdown for this page."
```

removedOutput schema / properties / has_more / description

Removed value: -"True when more pages of parts follow."

removedOutput schema / properties / page / description
```
Removed value: -"Current page number (1-based)."
```
removedOutput schema / properties / page_size / description
```
Removed value: -"Maximum number of parts per page."
```
removedOutput schema / properties / part_count / description
```
Removed value: -"Number of parts consumed on this page."
```
removedOutput schema / properties / total_parts / description
```
Removed value: -"Total parts across the entire document."
```

First observedv0.9.0May 28, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Description adds behavioral context beyond the readOnlyHint annotation, such as output format and interleaving behavior. No contradictions 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.

Conciseness4/5

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

Concise with three sentences, front-loading the main purpose. The middle sentence could be seen as extraneous but overall efficient.

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

Completeness3/5

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

Covers main purpose and important warnings, but lacks explanation of pagination parameters and does not mention output structure despite having an output schema.

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

Parameters2/5

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

Description does not add meaning to parameters beyond the schema. Schema covers 60% but page_size and page_number lack descriptions; the tool description does not clarify them.

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?

Clearly states the tool renders a document as flowing Markdown for reading. Distinguishes from siblings like get_document and list_work_items by specifying different use cases.

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 says it is the way to read a body, warns against using output for update_document, and directs to get_document for round-trip and list_work_items for metadata-only extraction.

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

Deploy Server