Skip to main content
Glama

get_projects

Retrieve and filter development projects from Wakapi time tracking data to analyze coding activity and productivity insights.

Instructions

Retrieve and filter the user's projects.

operationId: get-wakatime-projects summary: Retrieve and filter the user's projects description: Mimics https://wakatime.com/developers#projects tags: [wakatime] parameters:

  • name: user in: path description: User ID to fetch data for (or 'current') required: true schema: type: string

  • name: q in: query description: Query to filter projects by schema: type: string responses: 200: description: OK schema: v1.ProjectsViewModel

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userNocurrent
qNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes

Implementation Reference

  • The main handler function decorated with @app.tool that implements the logic for the 'get_projects' MCP tool. It includes type annotations for parameters and return type (ProjectsViewModel), detailed OpenAPI schema in the docstring, fetches data using the Wakapi client, handles errors, and returns the projects.
    @app.tool
    async def get_projects(
        user: str = "current", q: Optional[str] = None
    ) -> ProjectsViewModel:
        """Retrieve and filter the user's projects.
    
        operationId: get-wakatime-projects
        summary: Retrieve and filter the user's projects
        description: Mimics https://wakatime.com/developers#projects
        tags: [wakatime]
        parameters:
          - name: user
            in: path
            description: User ID to fetch data for (or 'current')
            required: true
            schema:
              type: string
          - name: q
            in: query
            description: Query to filter projects by
            schema:
              type: string
        responses:
          200:
            description: OK
            schema: v1.ProjectsViewModel
    
        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
    
        logger.info(f"get_projects called with user={user}, q={q}")
        client = get_wakapi_client()
    
        try:
            projects = await client.get_projects(user=user, q=q)
            logger.info(f"get_projects result type: {type(projects)}")
            return projects
        except Exception as e:
            logger.error(f"Error in get_projects: {e}")
            raise ValueError(f"Failed to fetch projects: {e}") from e
  • main.py:133-135 (registration)
    The import statement in the initialize_tools function that triggers the registration of the get_projects tool. Importing the decorated function registers it with the MCP app.
    from mcp_tools.projects import get_projects
    
    _ = get_projects  # Trigger registration
  • OpenAPI-style schema definition in the docstring of the get_projects handler, specifying parameters (user, q), responses, and authentication requirements for input/output validation.
    """Retrieve and filter the user's projects.
    
    operationId: get-wakatime-projects
    summary: Retrieve and filter the user's projects
    description: Mimics https://wakatime.com/developers#projects
    tags: [wakatime]
    parameters:
      - name: user
        in: path
        description: User ID to fetch data for (or 'current')
        required: true
        schema:
          type: string
      - name: q
        in: query
        description: Query to filter projects by
        schema:
          type: string
    responses:
      200:
        description: OK
        schema: v1.ProjectsViewModel
    
    Requires ApiKeyAuth: Set header `Authorization` to your API Key
    encoded as Base64 and prefixed with `Basic`.
    """
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. It discloses authentication requirements ('Requires ApiKeyAuth') and references the API endpoint, which is helpful. However, it doesn't mention rate limits, pagination behavior, error responses, or what happens when filtering returns no results—significant gaps for a tool with no annotation coverage.

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 extensive OpenAPI specification details (operationId, summary, parameters, responses) that duplicate information already in structured fields. This adds verbosity without proportional value, though the authentication note at the end is necessary and well-placed.

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 moderate complexity (2 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers authentication, parameters, and references the external API, though it could better explain behavioral aspects like error handling. The presence of an output schema reduces the need to describe return values in the description.

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

Parameters2/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 ('User ID to fetch data for (or 'current')') and 'q' parameter ('Query to filter projects by'), adding meaningful context beyond the bare schema. However, it doesn't clarify what 'current' means in practice or provide examples of valid query formats, leaving some ambiguity.

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 filter') and resource ('user's projects'), making the purpose evident. It distinguishes from some siblings like 'get_user' or 'get_stats' by focusing specifically on projects, though it doesn't explicitly differentiate from 'get_project_detail' which retrieves a single project versus this tool's list/filter functionality.

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_project_detail' for single project details or 'get_stats' for project statistics, leaving the agent to infer usage context from tool names alone.

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