Skip to main content
Glama

get_user

Retrieve user data from Wakatime to access coding statistics and productivity insights for analysis and tracking.

Instructions

Retrieve the given user.

operationId: get-wakatime-user summary: Retrieve the given user description: Mimics https://wakatime.com/developers#users tags: [wakatime] parameters:

  • name: user in: path description: User ID to fetch (or 'current') required: true schema: type: string responses: 200: description: OK schema: v1.UserViewModel

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userNocurrent

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes

Implementation Reference

  • The core handler function for the MCP 'get_user' tool, decorated with @app.tool(). It retrieves the Wakapi client via dependency injection and calls its get_user method, returning a UserViewModel or raising ValueError on failure. Includes OpenAPI-style docstring defining input/output schema.
    @app.tool
    async def get_user(user: str = "current") -> UserViewModel:
        """Retrieve the given user.
    
        operationId: get-wakatime-user
        summary: Retrieve the given user
        description: Mimics https://wakatime.com/developers#users
        tags: [wakatime]
        parameters:
          - name: user
            in: path
            description: User ID to fetch (or 'current')
            required: true
            schema:
              type: string
        responses:
          200:
            description: OK
            schema: v1.UserViewModel
    
        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:
            user_model: UserViewModel = await client.get_user(user=user)
            return user_model
        except Exception as e:
            raise ValueError(f"Failed to fetch user: {e}") from e
  • main.py:139-141 (registration)
    Import statement and reference in initialize_tools() that triggers the automatic registration of the get_user tool via its @app.tool decorator.
    from mcp_tools.users import get_user
    
    _ = get_user  # Trigger registration
  • Pydantic BaseModel defining the output schema (UserViewModel) returned by the get_user tool, wrapping the User data model.
    class UserViewModel(BaseModel):
        """Model for user view."""
    
        data: User
  • Underlying WakapiClient.get_user method called by the MCP tool handler. Performs the actual HTTP request to the Wakapi API and validates the response into UserViewModel.
    async def get_user(self, user: str = "current") -> UserViewModel:
        """
        Retrieve the given user.
    
        operationId: get-wakatime-user
        summary: Retrieve the given user
        description: Mimics https://wakatime.com/developers#users
        tags: [wakatime]
        parameters:
          - name: user
            in: path
            description: User ID to fetch (or 'current')
            required: true
            schema:
              type: string
        responses:
          200:
            description: OK
            schema: v1.UserViewModel
    
        Requires ApiKeyAuth: Set header `Authorization` to your API Key
        encoded as Base64 and prefixed with `Basic`.
        """
        url = f"{self.base_url}{self.api_path}/users/{user}"
    
        logger = logging.getLogger(__name__)
        logger.debug("Calling real Wakapi API for get_user")
        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_user: {e.response.status_code} - "
                f"{e.response.text}",
                details={"status_code": e.response.status_code, "method": "get_user"},
            ) from e
    
        json_data = response.json()
        return UserViewModel.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 adds some context by specifying authentication requirements (ApiKeyAuth with Basic header) and referencing the external API, but lacks details on error handling, rate limits, or response structure beyond the schema reference. This is adequate but has clear 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 front-loaded with the core purpose but includes verbose OpenAPI-like details (e.g., operationId, tags, responses) that could be streamlined. Some sentences, like the API mimic reference, add value, but others repeat structured information, reducing efficiency.

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 the tool's low complexity (1 parameter) and the presence of an output schema, the description is reasonably complete. It covers authentication, parameter semantics, and references the API, though it could benefit from more behavioral context like error cases or usage examples to be fully comprehensive.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It explains the 'user' parameter as 'User ID to fetch (or 'current')', which adds meaning beyond the schema's basic type and title. However, it doesn't detail format constraints or examples, leaving some ambiguity, so it meets the baseline for partial compensation.

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 verb 'retrieve' and the resource 'user', making the purpose evident. However, it does not explicitly differentiate this tool from sibling tools like 'get_stats' or 'get_leaders', which might also retrieve user-related data in different contexts, so it falls short of a perfect score.

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, such as whether it's for fetching basic user info compared to more detailed stats from sibling tools. It mentions the API endpoint it mimics but offers no context-specific usage advice.

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