Skip to main content
Glama

manage-time-tracking

Log work hours, manage time-off requests, and track holidays using a single tool with bulk actions and reporting capabilities.

Instructions

Consolidated tool for managing all time tracking entities (logged-time, timeoff, timeoff-types, public-holidays, team-holidays). Handles time logging, leave management, and holiday tracking through a decision-tree approach with comprehensive reporting capabilities.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe entity ID (logged_time_id, timeoff_id, timeoff_type_id, holiday_id)
dateNoFilter by specific date (YYYY-MM-DD)
nameNoName of the time off type or holiday
pageNoPage number for pagination
typeNoHoliday type
yearNoYear for the holiday
colorNoColor (hex code)
hoursNoHours logged or time off hours
notesNoNotes or description for logged time entries or holidays
activeNoFilter by active status (0=archived, 1=active)
fieldsNoComma-separated list of fields to return
formatNoResponse format - either "json" or "xml"json
lockedNoFilter by locked status (1=locked, 0=unlocked)
regionNoRegion or country code
statusNoFilter by status (pending, approved, rejected)
all_dayNoAll day flag (0=not all day, 1=all day)
countryNoCountry name
task_idNoFilter by task ID
billableNoFilter by billable status (1=billable, 0=non-billable)
end_dateNoFilter by end date (YYYY-MM-DD)
full_dayNoFull day flag (1=full day, 0=partial day)
moveableNoMoveable flag (0=fixed, 1=moveable)
per-pageNoNumber of items per page (max 200)
timezoneNoTimezone
operationYesThe time tracking operation to perform
people_idNoFilter by person ID
recurringNoFilter by recurring status (0=one-time, 1=recurring)
region_idNoFilter by region ID
created_byNoUser ID who created
is_defaultNoDefault flag (0=not default, 1=default)
project_idNoFilter by project ID
repeat_endNoRepeat end date
start_dateNoFilter by start date (YYYY-MM-DD)
approved_atNoApproval timestamp
approved_byNoUser ID who approved
descriptionNoHoliday description
entity_typeYesThe type of time tracking entity (logged-time, timeoff, timeoff-types, public-holidays, team-holidays)
rejected_atNoRejection timestamp
rejected_byNoUser ID who rejected
holiday_typeNoHoliday type (0=full day, 1=partial day)
repeat_stateNoRepeat state
department_idNoFilter by department ID
reference_dateNoReference date for UI suggestions
timeoff_entriesNoArray of time off entries for bulk creation
timeoff_type_idNoFilter by time off type ID
recurrence_patternNoRecurrence pattern
logged_time_entriesNoArray of logged time entries for bulk creation
Behavior2/5

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

No annotations are present, so the description carries full burden. It does not disclose behavioral traits such as authentication requirements, rate limits, error handling, or what happens with incorrect usage. The mention of 'comprehensive reporting' is vague and insufficient.

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 a single sentence, making it concise, but it is a run-on sentence that lacks structure. It attempts to cover too much without clear segmentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (47 parameters, 27 operations, 5 entity types), the description is far too brief. It does not explain the decision-tree logic, parameter dependencies per operation, or output format. No output schema is provided, leaving agents with inadequate context.

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%, so the schema already documents all parameters. The description adds no extra meaning beyond stating 'decision-tree approach' and 'comprehensive reporting', which does not enhance parameter understanding.

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 identifies the tool as a consolidated endpoint for time tracking entities (logged-time, timeoff, etc.) and mentions a decision-tree approach. It differentiates from sibling tools by being a unified gateway, but could be more specific about which operations are covered.

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?

No guidance is provided on when to use this consolidated tool versus the numerous sibling tools for specific CRUD operations. The description mentions a 'decision-tree approach' but does not explain how to navigate it or when it is preferable to individual endpoints.

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/asachs01/float-mcp'

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