Skip to main content
Glama
opositatest

swimlane-mcp

by opositatest
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_time_entries

Read-onlyIdempotent

Retrieves detailed time entries from KanbanFlow boards, showing who tracked time, when, how long, and on which task, with per-day and per-person breakdowns.

Instructions

Returns the time entries of KanbanFlow boards: every tracked interval with who tracked it, when it started and ended, how long it lasted and on which task. This is the only tool that breaks time down by day and by person; timeSpentHours in the other tools is the accumulated total of a task. Entries are found through the board activity log (totalSecondsSpent changes) unless you pass taskIds, and then read task by task. Totals are sums of entry durations, reported per person/board and per UTC day; two people working on the same task at the same time add up twice, so they are not elapsed time. meta reports the window, whether the activity log was read completely, entries that fell outside the window or have no end, and every API request made. The server does not interpret the board.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd of the window, ISO 8601 UTC (default: now).
fromNoStart of the window, ISO 8601 UTC (default: 2 days before "to", which covers a local "today" in any time zone). The server does not decide what "today" or "this week" is: pass the window the user means, in their time zone. An entry is included when its start falls inside the window.
limitNoMaximum entries returned, newest first (default 100, max 500). Totals always cover every match.
boardsNoBoard ids or exact names to search (see list_boards). Default: every configured board.
personNoOnly entries tracked by this person (user id, email, full name or part of the name). Use "me" for the configured user. Entries are attributed by the `userId` KanbanFlow records on each entry, which may be an integration id that is not a board member (then it is returned without a name). Omit it for everybody.
taskIdsNoRead only these tasks (ids from list_tasks, search_tasks or get_task) instead of scanning the activity log for the window. Cheaper and exact when you already know the tasks; also the way to reach entries older than the activity log keeps.
maxTasksNoMaximum tasks whose time entries are read (default 50, max 100), most recently changed first. Each task costs one API request.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive), and the description adds genuinely non-obvious behavior: the double-counting rule ('two people working on the same task at the same time add up twice, so they are not elapsed time'), what `meta` reports (window, log completeness, entries with no end, every API request), and that the server does not interpret the board.

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?

Front-loaded with the return semantics and the sibling differentiation before the retrieval mechanics and `meta` caveats. Dense but nearly every clause carries load; the `meta` enumeration is the one segment that could be tightened.

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?

For a 7-param, no-output-schema, open-world tool, the description supplies the retrieval strategy, aggregation semantics, window semantics, and return-shape caveats an agent needs to call it correctly. Nothing material is missing.

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?

Schema coverage is already 100%, so the baseline is 3, but the description adds operational meaning beyond the schema: the inclusion rule ('An entry is included when its start falls inside the window'), the cost model for `maxTasks` ('Each task costs one API request'), and why `taskIds` exists. It stops short of adding anything to `limit`/`boards` beyond the schema.

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?

States a specific verb and resource ('Returns the time entries of KanbanFlow boards') and enumerates the payload fields (who tracked it, start/end, duration, task). It explicitly distinguishes itself from siblings by noting it is 'the only tool that breaks time down by day and by person' while `timeSpentHours` elsewhere is a task total.

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?

Gives the decision rule for the main fork: entries come from the board activity log unless `taskIds` is passed, and `taskIds` is recommended when the tasks are known because it is 'cheaper and exact' and reaches history older than the activity log. It also states when to omit `person` ('Omit it for everybody') and what the default window covers.

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

Deploy Server

Other Tools