MCP Teamleader Focus

teamleader_get_time_tracking

Retrieve detailed information about a specific time-tracking entry using its unique ID. Get start time, duration, project, and associated task details to monitor logged hours.

Instructions

Get detailed information about a specific time-tracking entry.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "teamleader_get_time_tracking"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	The time tracking entry ID

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.2Sep 25, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the burden of explaining behavior. 'Get' indicates a read operation and 'detailed information' suggests the return payload, but it does not disclose error behavior, permission requirements, or whether the entry is returned in full. It is adequate but not rich.

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?

A single sentence with no filler; the description is appropriately sized for a simple getter tool. It communicates the core purpose immediately and every word contributes.

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?

For a one-parameter get operation, the description plus schema is mostly sufficient: the agent knows the resource, the input, and that detailed information is returned. It lacks explicit guidance on distinguishing from the list tool and does not describe return shape, but the low complexity makes this a minor gap.

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?

The schema fully documents the only parameter, 'id', with the description 'The time tracking entry ID', so schema coverage is 100%. The tool description adds no extra parameter-level meaning beyond identifying the entry type, and the baseline of 3 applies.

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 states a clear verb ('Get'), a specific resource ('time-tracking entry'), and signals a singular/detailed operation ('detailed information', 'specific'). This distinguishes it from the sibling list tool, teamleader_list_time_tracking, though it does not explicitly name that alternative.

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?

Usage is implied: it is the tool to use when you need details about one time-tracking entry, as opposed to listing entries. However, it does not explicitly say when to prefer this over teamleader_list_time_tracking or how to obtain the required id.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server