Skip to main content
Glama

get_polarion_document

Access structured documents like specifications and manuals from Polarion spaces using project ID, space ID, and document name to retrieve organized requirement collections.

Instructions

<purpose>Access specific structured documents within a Polarion space</purpose>

<when_to_use>
- When you need access to organized documents (specifications, manuals)
- When user provides specific space and document names
- When work items reference specific documents that need direct access
- For accessing curated requirement collections in document format
</when_to_use>

<workflow_position>
STEP 1: Use get_polarion_projects() to identify project
STEP 2: Use get_polarion_work_items() to explore and potentially discover space references
STEP 3: Use this tool when you have specific space_id and document_name
ALTERNATIVE: Often get_polarion_work_items() provides equivalent or better information
</workflow_position>

<parameters>
- project_id: Required. From get_polarion_projects()
- space_id: Required. EXACT space name (user-provided or from work item references)
- document_name: Required. Document name (e.g., "HMI", "System Requirements Specification")
- fields: "@basic" for summary, "@all" for complete content
</parameters>

<examples>
- HMI specifications: project_id="AutoCar", space_id="Master Specifications", document_name="HMI"
- System requirements: project_id="AutoCar", space_id="Requirements", document_name="System"
</examples>

<critical_requirements>
- space_id must be EXACT name (case-sensitive)
- document_name is case-sensitive
- Use quotes around space names with spaces (e.g., "Master Specifications")
- Space names typically provided by user or discovered from work item exploration
</critical_requirements>

<output>
Structured document content including organized requirements and specifications
Often contains similar information to work items but in document format
</output>

<troubleshooting>
If 404 error: Verify space_id and document_name spelling
Common spaces: "Master Specifications", "Requirements", "Design Documents"
Try exploring with get_polarion_work_items() first for context
</troubleshooting>

<note>
Space names are not discoverable via API - they come from user knowledge or work item references
</note>

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
document_nameYes
fieldsNo@basic
project_idYes
space_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • MCP tool handler function for 'get_polarion_document'. Registers the tool with @mcp.tool() decorator and implements the core logic by calling PolarionClient.get_document(), formatting success/error JSON responses.
    @mcp.tool()
    def get_polarion_document(project_id: str, space_id: str, document_name: str, fields: str = "@basic") -> str:
        """
        <purpose>Access specific structured documents within a Polarion space</purpose>
        
        <when_to_use>
        - When you need access to organized documents (specifications, manuals)
        - When user provides specific space and document names
        - When work items reference specific documents that need direct access
        - For accessing curated requirement collections in document format
        </when_to_use>
        
        <workflow_position>
        STEP 1: Use get_polarion_projects() to identify project
        STEP 2: Use get_polarion_work_items() to explore and potentially discover space references
        STEP 3: Use this tool when you have specific space_id and document_name
        ALTERNATIVE: Often get_polarion_work_items() provides equivalent or better information
        </workflow_position>
        
        <parameters>
        - project_id: Required. From get_polarion_projects()
        - space_id: Required. EXACT space name (user-provided or from work item references)
        - document_name: Required. Document name (e.g., "HMI", "System Requirements Specification")
        - fields: "@basic" for summary, "@all" for complete content
        </parameters>
        
        <examples>
        - HMI specifications: project_id="AutoCar", space_id="Master Specifications", document_name="HMI"
        - System requirements: project_id="AutoCar", space_id="Requirements", document_name="System"
        </examples>
        
        <critical_requirements>
        - space_id must be EXACT name (case-sensitive)
        - document_name is case-sensitive
        - Use quotes around space names with spaces (e.g., "Master Specifications")
        - Space names typically provided by user or discovered from work item exploration
        </critical_requirements>
        
        <output>
        Structured document content including organized requirements and specifications
        Often contains similar information to work items but in document format
        </output>
        
        <troubleshooting>
        If 404 error: Verify space_id and document_name spelling
        Common spaces: "Master Specifications", "Requirements", "Design Documents"
        Try exploring with get_polarion_work_items() first for context
        </troubleshooting>
        
        <note>
        Space names are not discoverable via API - they come from user knowledge or work item references
        </note>
        """
        logger.info(f"Fetching document {document_name} from space {space_id} in project {project_id}")
        document = polarion_client.get_document(project_id, space_id, document_name, fields)
        if document:
            return json.dumps({
                "status": "success",
                "message": f"Successfully fetched document: {document_name} from space {space_id} in project {project_id}",
                "document": document
            }, indent=2)
        return json.dumps({
            "status": "error",
            "message": f"Failed to fetch document {document_name} from space {space_id} in project {project_id}. Document may not exist or access is denied."
        }, indent=2)
  • Core helper method in PolarionClient that performs the actual REST API call to retrieve the Polarion document using the constructed endpoint and handles response/error cases.
    def get_document(self, project_id: str, space_id: str, document_name: str, fields: str = "@basic") -> Optional[Dict]:
        """Fetch a specific document from Polarion REST API."""
        try:
            self._ensure_token()
            api_url = f"{POLARION_BASE_URL}/rest/v1/projects/{project_id}/spaces/{space_id}/documents/{document_name}"
            params = {'fields[documents]': fields}
            response = self.session.get(api_url, params=params, headers=self._headers(), timeout=REQUEST_TIMEOUT_SECONDS)
            if response.status_code == 404:
                logger.warning(f"Document not found: {document_name} in space: {space_id} of project: {project_id}")
                return None
            self._handle_api_response(response, f"fetch document {document_name} from space {space_id} in project {project_id}")
            document_data = response.json()
            logger.info(f"Fetched document: {document_name} from space: {space_id} in project: {project_id}")
            return document_data
        except Exception as e:
            logger.error(f"Failed to fetch document {document_name} from space {space_id} in project {project_id}: {e}")
            return None
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read operation (implied by 'access'), requires exact case-sensitive inputs, and includes troubleshooting tips for errors like 404s. However, it lacks details on rate limits, authentication needs, or pagination, leaving some gaps.

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

Conciseness3/5

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

The description is well-structured with clear sections, but it is verbose with redundant information (e.g., repeating parameter details in multiple sections). Some sentences could be condensed, such as merging examples and critical requirements, to improve efficiency without losing clarity.

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 tool's complexity (4 parameters, no annotations, 0% schema coverage) and the presence of an output schema, the description is highly complete. It covers purpose, usage, parameters, examples, troubleshooting, and notes, providing all necessary context for an agent to use the tool effectively without needing to explain return values.

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

Parameters5/5

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

The schema has 0% description coverage, so the description must fully compensate. It adds significant meaning beyond the schema by explaining each parameter's purpose (e.g., project_id from get_polarion_projects(), space_id as exact name, document_name examples), providing examples, and noting critical requirements like case-sensitivity and quoting rules.

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 the tool's purpose as 'Access specific structured documents within a Polarion space' and distinguishes it from siblings by specifying it's for documents (not projects or work items). The examples further clarify it retrieves documents like specifications and manuals, making the purpose specific and differentiated.

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?

The description provides explicit guidance on when to use this tool (e.g., when user provides space and document names, for accessing curated requirement collections) and when not to use it (suggesting get_polarion_work_items() as an alternative that might provide better information). The workflow_position section outlines a step-by-step process and explicitly names alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sdunga1/MCP-Polarion'

If you have feedback or need assistance with the MCP directory API, please join our Discord server