Skip to main content
Glama

List time entries

list_time_entries
Read-onlyIdempotent

List logged time entries with server-side filters for project, work package, user, dates, and activity. Optionally compute an accurate total for all matching entries, grouped by activity.

Instructions

List logged time, filtered server-side, with an optional accurate total.

Use it to answer "how much time went into this ticket?", "what did I book last week?" or "how much did the team spend on project X in June?". Filters combine with AND, so project_id + user='me' + a date range is one call.

Returns the standard list envelope: items of {id, hours, spent_on, comment, user, activity, work_package, project} plus pagination. hours is a float (1.5 = 1h30), never an ISO duration. With sum_hours=true the envelope also carries sums.total_hours over all matches and one groups bucket per activity with its own count and sums.total_hours — those cover the whole filtered set, so never add pages up yourself.

Pitfalls. Visibility is permission-bound: without the view-all-time-entries permission you see only your own entries, and a small total may mean "not allowed to see" rather than "nobody booked time". work_package_id scopes to that one work package — child work packages are not included, so a parent's roll-up needs a query per child. The summing path stops at 2000 entries and says so in notes; narrow the date range or the project when that happens rather than trusting the number.

Cross-references: book time with log_time; correct an entry with update_time_entry and remove one with delete_time_entry; the activity ids and names valid in a project come from get_project_metadata; the work package itself (including its aggregated spent_hours) comes from get_work_package.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number.
userNoWhose time to list: a numeric user id, or the literal 'me' for the token owner. Omit for everyone you are allowed to see — on most instances that is only your own entries unless you hold the view-all-time-entries permission.
to_dateNoLatest spent-on date, ISO YYYY-MM-DD, inclusive.
fetch_allNoAggregate every page of rows into one result instead of returning page 1. Capped at 500 items with a note when the cap bites; mutually exclusive with page. sum_hours already reads every matching entry for its total, with or without fetch_all.
from_dateNoEarliest spent-on date, ISO YYYY-MM-DD, inclusive. Combine with to_date for a range; either bound may be omitted for an open-ended one.
page_sizeNoEntries per page (max 100); the instance may clamp it lower and the returned pagination reports what actually came back.
sum_hoursNoCompute an accurate total over EVERY matching entry (not just this page) and break it down per activity. Costs one request per 100 matches and is capped at 2000 entries — a cap hit is reported in 'notes'. Leave false when you only need rows.
project_idNoOnly entries in this project (numeric id or identifier, from list_projects). Includes project-level entries that have no work package.
activity_idNoOnly entries booked on this activity. Activity ids are instance-specific and come from get_project_metadata(project_id=...).
work_package_idNoOnly entries booked on this work package. Ids come from search_work_packages / list_work_packages. The filter name differs between OpenProject versions; this tool probes the instance and uses the right one.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sumsNoPresent only when show_sums was requested.
itemsNoThe page of results.
notesNoDegradation markers: capped aggregations, unavailable modules, …
groupsNoPresent only when group_by was requested.
paginationYesTotal/page/page_size/has_more.
Behavior5/5

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

The description goes well beyond annotations by disclosing permission-bound visibility, the 2000-entry summing cap, page_size clamping, and the nuance that a small total may reflect permissions rather than actual data. These details complement the readOnlyHint/idempotentHint annotations without any contradiction.

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 lengthy but well-structured with labeled sections (purpose, examples, response format, pitfalls, cross-references). It front-loads the core function and every sentence adds value, making it appropriately sized for a complex 10-parameter tool.

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

Completeness5/5

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

The description covers the response envelope, pagination, sums, group buckets, caps, permissions, and related tools, leaving very little unanswered for an agent. With an output schema present, this level of context is fully sufficient.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the input schema already documents all 10 parameters, the description adds meaningful cross-parameter behavior, such as how sum_hours aggregates across all matches, fetch_all caps at 500, and work_package_id excludes child work packages. These enrich the schema descriptions and justify a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'List logged time, filtered server-side, with an optional accurate total,' a specific verb and resource, and immediately gives concrete example questions. It clearly distinguishes itself from sibling tools like log_time and update_time_entry in the cross-references.

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

Usage Guidelines5/5

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

The description includes explicit 'Use it to answer...' usage scenarios and states that filters combine with AND. It lists alternatives for booking, correcting, and deleting entries, and gives exclusions such as permission limits and the exclusion of child work packages.

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/kar-thik/openproject-mcp'

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