Skip to main content
Glama

get_polarion_work_item

Retrieve complete details, relationships, and metadata for specific Polarion work items identified through search results to analyze requirements, tasks, and specifications.

Instructions

<purpose>Get detailed information about a specific work item</purpose>

<when_to_use>
- AFTER using get_polarion_work_items() to identify specific work items of interest
- When you need complete details about a requirement, task, or specification
- When you need full content, relationships, and metadata
- For deep analysis of specific work items
</when_to_use>

<workflow_position>
STEP 1: Use get_polarion_work_items() to discover and filter work items
STEP 2: Identify specific work_item_id from the results
STEP 3: Use this tool to get complete details
STEP 4: Analyze relationships and linked items if needed
</workflow_position>

<parameters>
- project_id: Required. Must match project from previous search
- work_item_id: Required. Get from get_polarion_work_items() results
- fields: "@basic" for essential info, "@all" for complete details including relationships
</parameters>

<examples>
- Detailed requirement analysis: fields="@all"
- Quick verification: fields="@basic"
- Understanding relationships: fields="@all" (includes linked items)
</examples>

<output>
Complete work item details including:
- Full description and content
- Relationships to other work items
- Metadata and status information
- Approval and review information
</output>

<note>
Use this tool sparingly - only when you need detailed information about specific items
identified through get_polarion_work_items() searches
</note>

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNo@basic
project_idYes
work_item_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Handler function for the 'get_polarion_work_item' MCP tool. Includes @mcp.tool() decorator for registration, detailed parameter documentation as schema, execution logic calling the client helper, error handling, and JSON response formatting.
    @mcp.tool()
    def get_polarion_work_item(project_id: str, work_item_id: str, fields: str = "@basic") -> str:
        """
        <purpose>Get detailed information about a specific work item</purpose>
        
        <when_to_use>
        - AFTER using get_polarion_work_items() to identify specific work items of interest
        - When you need complete details about a requirement, task, or specification
        - When you need full content, relationships, and metadata
        - For deep analysis of specific work items
        </when_to_use>
        
        <workflow_position>
        STEP 1: Use get_polarion_work_items() to discover and filter work items
        STEP 2: Identify specific work_item_id from the results
        STEP 3: Use this tool to get complete details
        STEP 4: Analyze relationships and linked items if needed
        </workflow_position>
        
        <parameters>
        - project_id: Required. Must match project from previous search
        - work_item_id: Required. Get from get_polarion_work_items() results
        - fields: "@basic" for essential info, "@all" for complete details including relationships
        </parameters>
        
        <examples>
        - Detailed requirement analysis: fields="@all"
        - Quick verification: fields="@basic"
        - Understanding relationships: fields="@all" (includes linked items)
        </examples>
        
        <output>
        Complete work item details including:
        - Full description and content
        - Relationships to other work items
        - Metadata and status information
        - Approval and review information
        </output>
        
        <note>
        Use this tool sparingly - only when you need detailed information about specific items
        identified through get_polarion_work_items() searches
        </note>
        """
        logger.info(f"Fetching work item {work_item_id} from project {project_id}")
        work_item = polarion_client.get_work_item(project_id, work_item_id, fields)
        if work_item:
            return json.dumps({
                "status": "success",
                "message": f"Successfully fetched work item: {work_item_id} from project {project_id}",
                "work_item": work_item
            }, indent=2)
        return json.dumps({
            "status": "error",
            "message": f"Failed to fetch work item {work_item_id} from project {project_id}. Work item may not exist or access is denied."
        }, indent=2)
  • Supporting utility in PolarionClient class that performs the actual HTTP REST API request to retrieve the specific work item data from Polarion server, handles authentication, errors, and returns the raw data used by the handler.
    def get_work_item(self, project_id: str, work_item_id: str, fields: str = "@basic") -> Optional[Dict]:
        """Fetch a specific work item by ID from Polarion REST API."""
        try:
            self._ensure_token()
            api_url = f"{POLARION_BASE_URL}/rest/v1/projects/{project_id}/workitems/{work_item_id}"
            params = {'fields[workitems]': fields}
            response = self.session.get(api_url, params=params, headers=self._headers(), timeout=REQUEST_TIMEOUT_SECONDS)
            if response.status_code == 404:
                logger.warning(f"Work item not found: {work_item_id} in project: {project_id}")
                return None
            self._handle_api_response(response, f"fetch work item {work_item_id} from project {project_id}")
            work_item_data = response.json()
            logger.info(f"Fetched work item: {work_item_id} from project: {project_id}")
            return work_item_data
        except Exception as e:
            logger.error(f"Failed to fetch work item {work_item_id} from project {project_id}: {e}")
            return None
  • Input schema documentation within the tool's docstring, describing parameters, types, requirements, and usage examples.
    <parameters>
    - project_id: Required. Must match project from previous search
    - work_item_id: Required. Get from get_polarion_work_items() results
    - fields: "@basic" for essential info, "@all" for complete details including relationships
    </parameters>
    
    <examples>
    - Detailed requirement analysis: fields="@all"
    - Quick verification: fields="@basic"
    - Understanding relationships: fields="@all" (includes linked items)
    </examples>
    
    <output>
    Complete work item details including:
    - Full description and content
    - Relationships to other work items
    - Metadata and status information
    - Approval and review information
    </output>
    
    <note>
    Use this tool sparingly - only when you need detailed information about specific items
    identified through get_polarion_work_items() searches
    </note>
    """
  • The @mcp.tool() decorator registers this function as an MCP tool named 'get_polarion_work_item'.
    @mcp.tool()
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 the tool's behavior: it retrieves detailed information (implying read-only), specifies that it should be used 'sparingly' (hinting at potential rate limits or performance considerations), and outlines output details. However, it doesn't explicitly state authentication requirements or error handling, 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.

Conciseness4/5

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

The description is well-structured with clear sections (<purpose>, <when_to_use>, etc.), making it easy to parse. However, it includes some redundancy (e.g., <output> details could be inferred from the purpose) and is slightly verbose, though every section adds value. It's front-loaded with key information in the <purpose> and <when_to_use> sections.

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 (3 parameters, no schema descriptions, no annotations, but with an output schema), the description is highly complete. It covers purpose, usage guidelines, workflow integration, parameter semantics, examples, output details, and notes. The presence of an output schema means the description doesn't need to explain return values in depth, and it effectively fills all other gaps.

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 description coverage is 0%, so the description must compensate fully. The <parameters> section adds significant meaning beyond the schema: it explains that project_id must match previous searches, work_item_id comes from get_polarion_work_items results, and fields has specific values ('@basic' for essential info, '@all' for complete details). This provides crucial context not in the schema.

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 explicitly states the purpose with a specific verb ('Get detailed information') and resource ('about a specific work item'), distinguishing it from sibling tools like get_polarion_work_items (which lists items) and get_polarion_document (which focuses on documents). The <purpose> tag clearly articulates the tool's function without redundancy.

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 <when_to_use> section provides explicit guidance on when to use this tool (e.g., after get_polarion_work_items, for complete details) and when not to (implied by suggesting alternatives like get_polarion_work_items for discovery). The <workflow_position> and <note> sections further clarify its role in a multi-step process, making usage context very clear.

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