Skip to main content
Glama
tschoonj

Repology MCP Server

by tschoonj

get_maintainer_problems

Retrieve reported package issues for a specific maintainer to identify and address problems in repositories. Filter by repository or paginate results as needed.

Instructions

Get problems reported for packages maintained by a specific person.

Args:
    maintainer: Maintainer email address
    repository: Optional repository to limit results to
    start_from: Project name to start from for pagination

Returns:
    JSON formatted list of problems for the maintainer

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maintainerYes
repositoryNo
start_fromNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Primary MCP tool handler for 'get_maintainer_problems'. Registers the tool via @mcp.tool(), executes the logic by delegating to RepologyClient, handles exceptions, and returns JSON-formatted problems list.
    @mcp.tool()
    async def get_maintainer_problems(
        maintainer: str,
        repository: Optional[str] = None,
        start_from: Optional[str] = None,
        ctx: Context[ServerSession, AppContext] = None,
    ) -> str:
        """Get problems reported for packages maintained by a specific person.
    
        Args:
            maintainer: Maintainer email address
            repository: Optional repository to limit results to
            start_from: Project name to start from for pagination
    
        Returns:
            JSON formatted list of problems for the maintainer
        """
        try:
            client = ctx.request_context.lifespan_context.repology_client
            problems = await client.get_maintainer_problems(
                maintainer=maintainer, repository=repository, start_from=start_from
            )
    
            if not problems:
                msg = f"No problems found for maintainer '{maintainer}'"
                if repository:
                    msg += f" in repository '{repository}'"
                return json.dumps({"message": msg})
    
            return _problems_to_json(problems)
    
        except RepologyNotFoundError:
            return json.dumps({"error": f"Maintainer '{maintainer}' not found"})
        except RepologyAPIError as e:
            await ctx.error(f"Repology API error: {e}")
            return json.dumps({"error": str(e)})
        except Exception as e:
            await ctx.error(f"Unexpected error getting maintainer problems: {e}")
            return json.dumps({"error": f"Unexpected error: {e}"})
  • RepologyClient helper method that constructs the API endpoint, makes the HTTP request to Repology, validates response data using Problem models, and returns list of Problem objects.
    async def get_maintainer_problems(
        self,
        maintainer: str,
        repository: Optional[str] = None,
        start_from: Optional[str] = None,
    ) -> ProblemsData:
        """Get problems for packages maintained by a specific person.
    
        Args:
            maintainer: Maintainer email address
            repository: Optional repository to limit results to
            start_from: Project name to start from for pagination
    
        Returns:
            List of problems
        """
        if repository:
            endpoint = (
                f"maintainer/{quote(maintainer)}/problems-for-repo/{quote(repository)}"
            )
        else:
            endpoint = f"maintainer/{quote(maintainer)}/problems"
    
        params = {}
        if start_from:
            params["start"] = start_from
    
        try:
            data = await self._make_request(endpoint, params)
    
            if not isinstance(data, list):
                raise RepologyAPIError(f"Expected list, got {type(data)}")
    
            problems = []
            for item in data:
                try:
                    problems.append(Problem.model_validate(item))
                except ValidationError as e:
                    print(f"Warning: Failed to validate problem data: {e}")
                    continue
    
            return problems
    
        except Exception as e:
            raise RepologyAPIError(f"Failed to get maintainer problems: {e}")
  • Pydantic schema/model for Problem objects, used to validate and structure the data returned by the Repology API in get_maintainer_problems.
    class Problem(BaseModel):
        """A problem reported for a package."""
    
        type: str = Field(description="Problem type")
        data: Dict[str, Any] = Field(description="Additional problem details")
        project_name: str = Field(description="Repology project name")
        version: str = Field(description="Package version")
        srcname: Optional[str] = Field(None, description="Source package name")
        binname: Optional[str] = Field(None, description="Binary package name")
        rawversion: Optional[str] = Field(None, description="Raw package version")
  • Helper utility to serialize list of Problem models to pretty-printed JSON string for the tool response.
    def _problems_to_json(problems: List[Problem]) -> str:
        """Convert problems list to formatted JSON string."""
        return json.dumps([prob.model_dump() for prob in problems], indent=2)
  • MCP tool registration decorator that registers the get_maintainer_problems function as an MCP tool.
    @mcp.tool()
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns a 'JSON formatted list of problems' and implies pagination via 'start_from', but it doesn't cover critical aspects like whether this is a read-only operation (likely, but not stated), potential rate limits, authentication requirements, error handling, or what constitutes a 'problem'. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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 and concise, with zero wasted words. It starts with a clear purpose statement, followed by bullet-point-like sections for 'Args' and 'Returns' that are easy to parse. Every sentence adds value, and the information is front-loaded, making it efficient for an AI agent to understand quickly.

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?

Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters adequately, and the presence of an output schema means it doesn't need to detail return values. However, it lacks behavioral context (e.g., safety, limits) and usage guidelines relative to siblings, which are important for a tool with no annotations. This makes it minimally viable but with clear gaps.

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 description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'maintainer' is an email address, 'repository' is optional to limit results, and 'start_from' is for pagination starting from a project name. This clarifies the purpose and usage of all three parameters, compensating well for the lack of schema descriptions. However, it doesn't specify formats (e.g., email validation) or pagination details, keeping it from a perfect score.

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

Purpose4/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: 'Get problems reported for packages maintained by a specific person.' It specifies the verb ('Get'), resource ('problems'), and scope ('for packages maintained by a specific person'), which is more specific than just restating the name. However, it doesn't explicitly differentiate from sibling tools like 'get_repository_problems' or 'search_projects', which might also retrieve problems in different contexts.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_repository_problems' (which might fetch problems by repository instead of maintainer) or 'search_projects' (which could involve problem searches). There are no explicit when-to-use or when-not-to-use instructions, leaving usage context implied at best.

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/tschoonj/repology-mcp-server'

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