Skip to main content
Glama

Get project report data

get_project_report_data
Read-onlyIdempotent

Get all status-report data for a project and date window in one call: work-package changes, open counts, time entries, and team roster.

Instructions

Aggregate everything a status report needs about one project and one date window.

Use it for weekly reports, sprint reviews, standups and "what happened in June" — one call replaces a dozen filtered listings. It returns, for the window: created, updated and closed work-package buckets (each {items, total, truncated, more_via} with compact rows), open_total plus open_by_status counts computed server-side over the whole open set, a time summary (total hours with per-activity and per-user breakdowns) and the project's membership roster.

Done/in-progress classification is safe here: every row carries is_closed, read from the status's own isClosed flag on this instance, so it works on translated and renamed workflows where matching status names would not. closed is exactly "in a closed status and touched inside the window" — the done-this-week set.

Pitfalls. Counts and row lists are different things: total is always the server's number, while items stops at an internal cap and then sets truncated and adds a notes entry — quote the count, not the row count. open_by_status covers the open set as it is now, not as it was during the window. updated includes the rows in closed. Time visibility is permission-bound, so a total_hours of 0 can mean "not allowed to see" rather than "nobody logged time" — an unreadable time ledger and an unreadable roster each degrade into a notes entry instead of failing the call. Read notes before calling any number complete.

Cross-references: rendered reports are the weekly_report and daily_standup prompts, which run this same aggregation server-side; drill into a bucket with list_work_packages, into hours with list_time_entries, and into one row with get_work_package.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
to_dateYesLast day of the report window, ISO YYYY-MM-DD, inclusive.
from_dateYesFirst day of the report window, ISO YYYY-MM-DD, inclusive. Required and never inferred — 'this week' means different days to different people.
project_idYesNumeric project id or project identifier (the URL slug). Both come from list_projects; the identifier is what appears in /projects/<identifier>.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeYesTime logged against the project inside the window.
notesNoIn-band markers: which lists were capped, which sources degraded. Read them before quoting a number as complete.
closedYesWork packages in a closed status that changed inside the window — the 'done this week' set.
rosterNoProject membership roster: who may act in the project and with which roles.
createdYesWork packages created inside the window (createdAt range filter).
projectNoThe project the report covers.
to_dateYesWindow end, ISO YYYY-MM-DD, inclusive.
updatedYesWork packages changed inside the window (updatedAt range filter). Includes the ones that were closed.
from_dateYesWindow start, ISO YYYY-MM-DD, inclusive.
open_totalNoOpen work packages in the project right now, server-reported.
open_by_statusNoServer-side groupBy=status counts over the whole open set, independent of paging. Never re-add these from rows.
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint/idempotentHint, but the description adds extensive behavioral context: truncation and `truncated`/`notes` behavior, `open_by_status` being 'as of *now*', `updated` including closed rows, permission-bound time visibility degrading into `notes` entries, and the `is_closed` flag robustness on translated workflows. This far exceeds the annotation baseline.

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?

The description is well-structured with clear sections: purpose, return contents, safe classification, pitfalls, and cross-references. Though long, every sentence conveys critical edge-case or usage information – it is dense but not bloated, and the key purpose is front-loaded.

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 the tool's complexity (multiple return buckets, truncation, permission-dependent fields, server-side computed counts), the description covers all major aspects: return structure, pitfalls, degradation behavior, and drill-down alternatives. The presence of an output schema further completes return-value understanding, so the description is fully adequate.

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% with detailed parameter descriptions (e.g., from_date explains inclusive ISO and that it's never inferred). The description does not add per-parameter semantics beyond the schema; it focuses on usage and return behavior. Per rubric, baseline 3 applies when schema fully documents parameters.

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?

Description opens with 'Aggregate everything a status report needs about one project and one date window' – a specific verb, resource, and scope. It distinguishes from sibling listing tools by saying 'one call replaces a dozen filtered listings' and enumerates exactly what it returns (buckets, counts, time summary, roster).

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 'Use it for weekly reports, sprint reviews, standups and "what happened in June"' and provides clear alternatives for drill-down: 'drill into a bucket with list_work_packages, into hours with list_time_entries, and into one row with get_work_package.' This gives both when-to-use and when-to-use-alternatives.

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