Skip to main content
Glama

TimeTac MCP by usefulapi

Start timer

timetac_start_time_tracking
Destructive

WRITE: start a timer for a user, now or at a given time. Each call can create a new running entry, so do not repeat it. TimeTac API: POST timeTrackings/start.

Input Schema

NameRequiredDescriptionDefault
notesNo
task_idNoThe task to book the time on.
user_idYesThe user the timer belongs to.
start_timeNoStart date-time. Leave empty to start now.
start_time_timezoneNoIANA time zone of start_time. Needed when start_time is set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations only give destructiveHint=true and a title, so the description carries real weight here. The leading "WRITE:" marker and the duplicate-entry warning disclose the key behavioral risk (repeat calls create additional running entries), which the annotations do not express.

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?

Three short sentences, front-loaded with the WRITE marker and the primary warning. No filler; the API endpoint note is a compact trailing detail.

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 5-param, single-required-field write tool with no output schema, the description covers the essential risk and timing modes. It leaves open what happens if the user already has a running timer, which would be the one useful addition.

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 coverage is 80%, so descriptions already document task_id, user_id, start_time and start_time_timezone. The description adds only the "now or at a given time" framing for start_time and nothing about the timezone dependency, so it sits at the baseline for high-coverage schemas.

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?

States a specific verb and resource (start a timer for a user) plus the two timing modes (now or at a given time). It is clearly separable from timetac_stop_time_tracking and timetac_create_time_tracking, though it doesn't name those siblings explicitly.

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

Usage Guidelines4/5

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

"Each call can create a new running entry, so do not repeat it" is an explicit, actionable warning against duplicate invocation. It stops short of naming alternatives (e.g., check timetac_current_time_trackings first, or use stop_time_tracking to end one).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.