Skip to main content
Glama

getTime

Retrieve logged time entries from Teamwork projects with filters for date ranges, project status, billing status, and sorting options to track work hours and generate reports.

Instructions

Get all time entries. Return all logged time entries for all projects. Only the time entries that the logged-in user can access will be returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
updatedAfterNofilter by updated after date
startDateNofilter by a starting date
reportFormatNodefine the format of the report
projectStatusNofilter by project status
orderModeNoorder mode
orderByNosort order
invoicedTypeNofilter by invoiced type
endDateNofilter by an ending date
billableTypeNofilter by billable type
updatedByNofilter by the user who updated the timelog
ticketIdNofilter by ticket id
tasklistIdNofilter by tasklist id
taskIdNofilter by task id (deprecated, use taskIds)
projectIdNofilter by project id (deprecated, use projectIds)
pageSizeNonumber of items in a page
pageNopage number
invoiceIdNofilter by invoice id
budgetIdNofilter by budget id
allocationIdNofilter by allocation id

Implementation Reference

  • MCP tool handler for 'getTime'. Calls the service with input params and returns JSON stringified response or error.
    export async function handleGetTime(input: any) {
      try {
        logger.info('Handling getTime tool request');
        const response = await getTimeService(input);
        
        logger.info('Successfully handled getTime request');
        return {
          content: [{
            type: "text",
            text: JSON.stringify(response, null, 2)
          }]
        };
      } catch (error: any) {
        return createErrorResponse(error, 'Getting time entries');
      }
    } 
  • Tool schema/definition for 'getTime' including inputSchema for parameters like dates, filters, pagination, etc.
    export const getTimeDefinition = {
      name: "getTime",
      description: "Get all time entries. Return all logged time entries for all projects. Only the time entries that the logged-in user can access will be returned.",
      inputSchema: {
        type: 'object',
        properties: {
          updatedAfter: {
            type: 'string',
            description: 'filter by updated after date'
          },
          startDate: {
            type: 'string',
            description: 'filter by a starting date'
          },
          reportFormat: {
            type: 'string',
            description: 'define the format of the report'
          },
          projectStatus: {
            type: 'string',
            description: 'filter by project status',
            enum: [
              'active',
              'current',
              'late',
              'upcoming',
              'completed',
              'deleted'
            ]
          },
          orderMode: {
            type: 'string',
            description: 'order mode',
            enum: [
              'asc',
              'desc'
            ]
          },
          orderBy: {
            type: 'string',
            description: 'sort order',
            enum: [
              'company',
              'date',
              'dateupdated',
              'project',
              'task',
              'tasklist',
              'user',
              'description',
              'billed',
              'billable',
              'timespent'
            ]
          },
          invoicedType: {
            type: 'string',
            description: 'filter by invoiced type',
            enum: [
              'all',
              'invoiced',
              'noninvoiced'
            ]
          },
          endDate: {
            type: 'string',
            description: 'filter by an ending date'
          },
          billableType: {
            type: 'string',
            description: 'filter by billable type',
            enum: [
              'all',
              'billable',
              'non-billable'
            ]
          },
          updatedBy: {
            type: 'integer',
            description: 'filter by the user who updated the timelog'
          },
          ticketId: {
            type: 'integer',
            description: 'filter by ticket id'
          },
          tasklistId: {
            type: 'integer',
            description: 'filter by tasklist id'
          },
          taskId: {
            type: 'integer',
            description: 'filter by task id (deprecated, use taskIds)'
          },
          projectId: {
            type: 'integer',
            description: 'filter by project id (deprecated, use projectIds)'
          },
          pageSize: {
            type: 'integer',
            description: 'number of items in a page'
          },
          page: {
            type: 'integer',
            description: 'page number'
          },
          invoiceId: {
            type: 'integer',
            description: 'filter by invoice id'
          },
          budgetId: {
            type: 'integer',
            description: 'filter by budget id'
          },
          allocationId: {
            type: 'integer',
            description: 'filter by allocation id'
          }
        },
        required: []
      },
      annotations: {
        title: "Get Time Entries",
        readOnlyHint: false,
        destructiveHint: false,
        openWorldHint: false
      }
    };
  • Registration of 'getTime' tool in the toolPairs array, mapping definition to handler for toolHandlersMap.
    { definition: getTime, handler: handleGetTime },
  • Core service function getTime that makes API call to '/time.json' with params and returns data. Called by the tool handler.
    export const getTime = async (params: GetTimeParams = {}) => {
      try {
        logger.info('Fetching time entries from Teamwork');
        
        const api = getApiClientForVersion('v3');
        
        logger.info('Making API request to get time entries');
        const response = await api.get('/time.json', { params });
        
        logger.info('Successfully retrieved time entries');
        return response.data;
      } catch (error: any) {
        logger.error(`Failed to get time entries: ${error.message}`);
        throw new Error(`Failed to get time entries: ${error.message}`);
      }
    };
Behavior3/5

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

Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=false, covering basic safety and scope. The description adds context about user accessibility filtering ('Only the time entries that the logged-in user can access will be returned'), which is valuable behavioral information not in the annotations. However, it lacks details on pagination behavior (implied by page/pageSize parameters), rate limits, or error handling, leaving gaps in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with two clear sentences: the first states the core purpose, and the second adds important behavioral context (user accessibility). There's no wasted verbiage, and it efficiently conveys key information. A slight deduction to 4 is due to the lack of explicit sibling differentiation, which could enhance structure.

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 complexity (19 parameters, no output schema) and rich annotations (covering safety and scope), the description is minimally adequate. It explains the tool's purpose and user-based filtering but doesn't address output format, pagination behavior, or error scenarios. With no output schema, more detail on return values would be beneficial, making it incomplete for full contextual understanding.

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 100%, with all 19 parameters well-documented in the schema itself (e.g., filter by dates, status, ordering). The description mentions 'all time entries' and user accessibility but doesn't add meaningful parameter-specific semantics beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate for any gaps.

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 all time entries. Return all logged time entries for all projects.' It specifies the resource (time entries) and scope (all projects, user-accessible). However, it doesn't explicitly differentiate from potential sibling tools like 'getProjectsAllocationsTime' or 'getTasksMetricsComplete' that might also involve time data, though those appear to have different focuses.

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

Usage Guidelines3/5

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

The description provides some usage context by stating 'Only the time entries that the logged-in user can access will be returned,' which implies permission-based filtering. However, it doesn't explicitly guide when to use this tool versus alternatives like 'getProjectsAllocationsTime' (which might focus on project-level time data) or other time-related tools not present in the sibling list. The guidance is implied rather than explicit.

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/Vizioz/Teamwork-MCP'

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