Skip to main content
Glama

get_leaders

Retrieve a ranked list of users based on coding activity to track team productivity and identify top contributors in development workflows.

Instructions

List of users ranked by coding activity in descending order.

operationId: get-wakatime-leaders summary: List of users ranked by coding activity in descending order. description: Mimics https://wakatime.com/developers#leaders tags: [wakatime] responses: 200: description: OK schema: v1.LeadersViewModel

Requires ApiKeyAuth: Set header Authorization to your API Key encoded as Base64 and prefixed with Basic.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
pageYes
rangeYes
languageYes
total_pagesYes
current_userNo

Implementation Reference

  • The MCP tool handler function for "get_leaders". It uses dependency injection to get the Wakapi client and calls its get_leaders method, with error handling.
    @app.tool
    async def get_leaders() -> LeadersViewModel:
        """List of users ranked by coding activity in descending order.
    
        operationId: get-wakatime-leaders
        summary: List of users ranked by coding activity in descending order.
        description: Mimics https://wakatime.com/developers#leaders
        tags: [wakatime]
        responses:
          200:
            description: OK
            schema: v1.LeadersViewModel
    
        Requires ApiKeyAuth: Set header `Authorization` to your API Key
        encoded as Base64 and prefixed with `Basic`.
        """
        from mcp_tools.dependency_injection import get_wakapi_client
    
        client = get_wakapi_client()
    
        try:
            return await client.get_leaders()
        except Exception as e:
            raise ValueError(f"Failed to fetch leaders: {e}") from e
  • main.py:136-138 (registration)
    The import statement in main.py that triggers the registration of the get_leaders tool via its @app.tool decorator.
    from mcp_tools.leaders import get_leaders
    
    _ = get_leaders  # Trigger registration
  • Pydantic BaseModel defining the structure of the LeadersViewModel, which is the return type of the get_leaders tool.
    class LeadersViewModel(BaseModel):
        """Model for leaders view."""
    
        current_user: Optional[LeadersCurrentUser] = None
        data: list[LeadersEntry]
        language: str
        page: int
        range: LeadersRange
        total_pages: int
  • The WakapiClient.get_leaders() method called by the tool handler, which makes the HTTP request to the Wakapi API and validates the response using LeadersViewModel.
    async def get_leaders(self) -> LeadersViewModel:
        """
        List of users ranked by coding activity in descending order.
    
        operationId: get-wakatime-leaders
        summary: List of users ranked by coding activity in descending order.
        description: Mimics https://wakatime.com/developers#leaders
        tags: [wakatime]
        responses:
          200:
            description: OK
            schema: v1.LeadersViewModel
    
        Requires ApiKeyAuth: Set header `Authorization` to your API Key
        encoded as Base64 and prefixed with `Basic`.
        """
        url = f"{self.base_url}{self.api_path}/leaders"
    
        logger = logging.getLogger(__name__)
        logger.debug("Calling real Wakapi API for get_leaders")
        try:
            response = await self.client.get(url, headers=self._get_headers())
            response.raise_for_status()
        except httpx.HTTPStatusError as e:
            raise ApiError(
                f"Wakapi API error in get_leaders: {e.response.status_code} - "
                f"{e.response.text}",
                details={
                    "status_code": e.response.status_code,
                    "method": "get_leaders",
                },
            ) from e
    
        json_data = response.json()
        return LeadersViewModel.model_validate(json_data)
Behavior3/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 does reveal important behavioral traits: it requires API key authentication with specific header formatting, and it returns a 200 response with a structured schema. However, it doesn't mention rate limits, pagination, error conditions, or whether this is a read-only operation (though 'list' implies read-only).

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 reasonably concise but has structural issues. The first sentence clearly states the purpose, but then includes API documentation details (operationId, summary, tags, responses) that might be redundant. The authentication instructions are necessary but could be more integrated. Some information feels like it belongs in structured fields rather than the description text.

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

Completeness4/5

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

Given that this tool has 0 parameters, 100% schema coverage, and an output schema exists, the description provides adequate context. It explains what the tool does, mentions the API endpoint it mimics, specifies authentication requirements, and indicates the response structure. For a parameterless read operation with output schema, this is reasonably complete, though it could benefit from more behavioral context.

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 input schema has 0 parameters with 100% description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't waste space discussing non-existent parameters. It does mention the authentication requirement which could be considered a parameter-like concern, though it's handled via headers rather than input parameters.

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: 'List of users ranked by coding activity in descending order.' This specifies the verb ('list'), resource ('users'), and ranking criteria ('coding activity'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_stats' or 'get_user' which might also involve user data.

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. While it mentions mimicking a WakaTime API endpoint, it doesn't explain when this leaderboard tool is appropriate compared to other user-related tools like 'get_user' or 'get_stats'. There's no mention of prerequisites or typical use cases.

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/impure0xntk/mcp-wakapi'

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