Skip to main content
Glama

get_team_worklog

Retrieve worklogs logged by each member of a Tempo team in a date range, grouped by worker, with optional breakdowns by day, project, or issue. Includes options for subtasks, active members, and excluding absence.

Instructions

Hours every member of a Tempo team logged in a date range, per worker.

Reproduces Tempo's "Logged Time" report grouped by worker (the Tempo.jspa#/reports/logged-time?teamId=…&groupBy=worker view): one worklog search filtered by teamId covers the whole team for [date_from, date_to] (both inclusive). The team roster is fetched separately so members who logged nothing still appear with 0 hours.

Args: team_id: Tempo team id (the teamId from the report URL, e.g. 79). date_from: Start date, inclusive, YYYY-MM-DD. date_to: End date, inclusive, YYYY-MM-DD. include_subtasks: Include worklogs on subtasks (the report's includeSubtasks toggle). Defaults to Tempo's own default. breakdown: Optional per-worker grouping — day, project, issue, both (=project+issue), all, or a comma combo like day,project. Each requested dimension appears as by_day / by_project / by_issue inside every worker's entry (e.g. day → hours-per-day per worker, the whole timesheet matrix, in ONE call — never call this once per user). only_active: Keep only current employees on an open team membership (default). Set False to include people who left the company or moved off the team — a team's roster accumulates them for years, so the default keeps the report to the people working now. exclude_absence: Drop vacation / sick-leave worklogs, which Tempo logs against a dedicated Absence account. Off by default so totals match Tempo's own report; turn it on to read the numbers as actual workload — otherwise a week of vacation looks identical to a week of work (8h/day either way).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
date_toYes
team_idYes
breakdownNo
date_fromYes
only_activeNo
exclude_absenceNo
include_subtasksNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

No annotations provided, so description fully discloses behavior: output includes per-worker entries with optional breakdowns (day, project, etc.), members with zero hours appear, and effects of include_subtasks, only_active, and exclude_absence parameters are detailed. No contradictions.

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?

Well-structured with an Args section and parameter descriptions. Front-loaded purpose. Slightly verbose but every sentence adds value; no wasted words.

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?

Given 7 parameters (all explained), output schema exists (so return format not needed), and annotations absent, the description covers all necessary context: usage, behavior, parameter semantics, and edge cases (zero-hour members, absence handling). Complete for a complex tool.

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

Parameters5/5

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

Schema coverage is 0%, but description compensates thoroughly: explains team_id source, date format and inclusivity, breakdown options and their output structure, only_active rationale (team roster accumulation), and exclude_absence impact (vacation vs work). Adds significant meaning beyond bare schema types.

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 specifies the exact resource (Tempo team worklog), action (get hours per member), and scope (date range, per worker). It distinguishes from siblings like get_user_worklog and get_users_worklog by focusing on team-level aggregation.

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?

Explicitly states this tool covers the whole team in one call, recommending against per-user calls. Provides context by referencing the Tempo report and explaining how the team roster is handled. Implicitly suggests alternatives by contrasting with single-user tools.

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/nsleader/jira-mcp'

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