Skip to main content
Glama

get_polarion_projects

Discover available Polarion projects to identify correct project IDs for requirements management operations and verify system authentication.

Instructions

<purpose>Discover available Polarion projects for exploration</purpose>

<when_to_use>
- ALWAYS use this FIRST when starting Polarion exploration
- When you need to find the correct project_id for other operations
- When user asks about projects without specifying project name
- To verify authentication is working
</when_to_use>

<workflow_position>
STEP 1: Use this tool first to discover available projects
STEP 2: Choose relevant project_id from results  
STEP 3: Use get_polarion_work_items() to explore project contents
STEP 4: Use get_polarion_work_item() for detailed information
</workflow_position>

<parameters>
- limit: Number of projects to retrieve (default 10, increase for comprehensive view)
</parameters>

<examples>
- Finding automotive projects: Look for "AutoCar", "Vehicle", "Car" in project names
- Comprehensive discovery: Use limit=50 to see all available projects
</examples>

<output>List of projects with basic info - use project 'id' field for subsequent calls</output>

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Main tool handler for get_polarion_projects. Decorated with @mcp.tool(), handles input validation via docstring, calls client.get_projects, formats and returns JSON response.
    @mcp.tool()
    def get_polarion_projects(limit: int = 10) -> str:
        """
        <purpose>Discover available Polarion projects for exploration</purpose>
        
        <when_to_use>
        - ALWAYS use this FIRST when starting Polarion exploration
        - When you need to find the correct project_id for other operations
        - When user asks about projects without specifying project name
        - To verify authentication is working
        </when_to_use>
        
        <workflow_position>
        STEP 1: Use this tool first to discover available projects
        STEP 2: Choose relevant project_id from results  
        STEP 3: Use get_polarion_work_items() to explore project contents
        STEP 4: Use get_polarion_work_item() for detailed information
        </workflow_position>
        
        <parameters>
        - limit: Number of projects to retrieve (default 10, increase for comprehensive view)
        </parameters>
        
        <examples>
        - Finding automotive projects: Look for "AutoCar", "Vehicle", "Car" in project names
        - Comprehensive discovery: Use limit=50 to see all available projects
        </examples>
        
        <output>List of projects with basic info - use project 'id' field for subsequent calls</output>
        """
        logger.info(f"Fetching {limit} projects from Polarion")
        projects = polarion_client.get_projects(limit)
        if projects:
            return json.dumps({
                "status": "success",
                "message": f"Successfully fetched {len(projects)} projects",
                "projects": projects,
                "count": len(projects)
            }, indent=2)
        return json.dumps({
            "status": "error",
            "message": "Failed to fetch projects. Please check authentication and token."
        }, indent=2)
  • Core helper method in PolarionClient that performs the actual REST API call to retrieve projects from Polarion, handles authentication, errors, and returns list of project dicts.
    def get_projects(self, limit: int = 10) -> List[Dict]:
        """Fetch projects from Polarion REST API (lightweight fields)."""
        try:
            self._ensure_token()
            api_url = f"{POLARION_BASE_URL}/rest/v1/projects"
            params = {
                'fields[projects]': '@basic',
                'page[size]': limit
            }
            response = self.session.get(api_url, params=params, headers=self._headers(), timeout=REQUEST_TIMEOUT_SECONDS)
            self._handle_api_response(response, "fetch projects")
            data = response.json()
            projects = (data.get('data') or [])[:limit]
            logger.info(f"Fetched {len(projects)} projects")
            return projects
        except Exception as e:
            logger.error(f"Failed to fetch projects: {e}")
            return []
  • Docstring sections defining input parameters and output format, used by FastMCP for schema validation.
    def get_polarion_projects(limit: int = 10) -> str:
        """
        <purpose>Discover available Polarion projects for exploration</purpose>
        
        <when_to_use>
        - ALWAYS use this FIRST when starting Polarion exploration
        - When you need to find the correct project_id for other operations
        - When user asks about projects without specifying project name
        - To verify authentication is working
        </when_to_use>
        
        <workflow_position>
        STEP 1: Use this tool first to discover available projects
        STEP 2: Choose relevant project_id from results  
        STEP 3: Use get_polarion_work_items() to explore project contents
        STEP 4: Use get_polarion_work_item() for detailed information
        </workflow_position>
        
        <parameters>
        - limit: Number of projects to retrieve (default 10, increase for comprehensive view)
        </parameters>
        
        <examples>
        - Finding automotive projects: Look for "AutoCar", "Vehicle", "Car" in project names
        - Comprehensive discovery: Use limit=50 to see all available projects
        </examples>
        
        <output>List of projects with basic info - use project 'id' field for subsequent calls</output>
        """
  • @mcp.tool() decorator registers the function as an MCP tool.
    @mcp.tool()
  • Global instantiation of PolarionClient used by all tool handlers.
    polarion_client = PolarionClient()
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 role in authentication verification, its position as the first step in exploration workflows, and its output usage (project 'id' field for subsequent calls). However, it doesn't mention potential rate limits, error conditions, or pagination behavior, which keeps it from a perfect score.

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?

The description is well-structured with clear XML-like tags (<purpose>, <when_to_use>, etc.) that make it easy to parse. Each section is front-loaded with essential information, and every sentence adds value—from purpose statements to practical examples. There is no redundant or verbose content.

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 low complexity (1 optional parameter) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage guidelines, workflow positioning, parameter semantics, examples, and output usage. No significant gaps remain for effective agent operation.

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

Parameters4/5

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

The schema has 0% description coverage for its single parameter (limit), but the description compensates by explaining the parameter's purpose ('Number of projects to retrieve'), default value ('default 10'), and usage guidance ('increase for comprehensive view'). It adds meaningful context beyond the schema's basic type information, though it doesn't specify maximum allowed values or validation 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 explicitly states the purpose as 'Discover available Polarion projects for exploration' with a clear verb ('Discover') and resource ('Polarion projects'). It distinguishes from siblings like get_polarion_project (singular) by emphasizing discovery of multiple projects, and from get_polarion_work_items by focusing on projects rather than work items.

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: 'ALWAYS use this FIRST when starting Polarion exploration', 'When you need to find the correct project_id for other operations', 'When user asks about projects without specifying project name', and 'To verify authentication is working'. It also positions this tool in a workflow with specific steps, clearly differentiating it from sibling tools like get_polarion_work_items.

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