Build repeatable reports with MCP
By Tristan Doehl · · Updated
A timer command changes one record. A weekly review needs several queries and a decision about what their results mean. Teetrack’s MCP tools can supply the records for that review, but a repeatable workflow also needs explicit dates, a clear output, and a way to handle incomplete results.
Define the report before asking for it
Choose the period, the projects, and the measures you need. A useful weekly report might show actual tracked hours, billable hours, and billable amounts by project. If you compare two weeks, use equivalent date ranges and identify the time zone used to interpret their boundaries.
An illustrative request is: “Compare Acme redesign from 23 February–1 March with 16–22 February 2026. Show tracked hours and billable hours for each week, then list the entries behind any difference. Keep currencies separate.” This defines the question and leaves the underlying records available for inspection.
Build the explanation from returned records
Use list_tracks with after, before, project_id, and done: true for each week. These date bounds are exclusive, so an entry that starts exactly at Monday 00:00 is left out, while get_project_summary counts it. Set after a second before the week begins to include it. Fetch every relevant page before adding the completed entries’ unrounded durations. Apply the same billable-status and time-zone rules to both weeks, and identify missing results if a query fails.
get_project_summary accepts date boundaries and a result limit, but applies your Teetrack rounding setting. Label those totals as rounded when rounding is enabled; a difference from the raw entries can come from that setting. get_time_summary takes no parameters and returns rolling totals counted back from the moment of the request. Its day, month, and year fields cover the last 24 hours, 30 days, and 365 days, and total covers all time. Running timers are included, and on Free no figure reaches further back than 90 days. Asked on 5 March, the month figure therefore reaches back into February, so it cannot stand in for a calendar month or compare two selected weeks.
A difference in hours describes a change in recorded work. It does not establish that productivity rose or a project stalled. Read the descriptions and consider leave, scope changes, and reporting gaps before attaching an explanation to the number.
Use a budget check to identify a decision
Project budgets require Business or Pro. get_budget_status accepts date boundaries and returns every project, with zero budget fields where no budget is set; it has no project filter. Select the intended project from the returned list and compare trackedHours with budgetHours, or actualAmount with budgetAmount. The overBudget flag turns true once the project’s alert threshold is reached, for example at 80%, so it does not by itself mean the budget has been exceeded. For a whole-project budget check, use dates covering the project’s work rather than only the reporting week. Budget consumption uses unrounded durations and amounts.
For example, a 40-hour project that has used 30 hours has 10 hours left. If the remaining review and implementation need an estimated 16 hours, the forecast exceeds the budget by 6 hours. The weekly report should identify the work to defer or the additional time to approve.
Separate a saved prompt from a schedule
A prompt saved for Monday is a reusable instruction. It runs when you submit it. To run without that step, an external scheduler must invoke an assistant or application with the required credentials, collect the results, and deliver the report. Teetrack’s MCP endpoint does not schedule a conversation merely because you ask it to check something regularly.
Begin scheduled work with read-only reporting. Define where its output goes, how a failure is reported, and who reviews the result. Sending email or posting to another service needs that service’s integration and authorisation in addition to the Teetrack connection.
Make retries safe for the records
A multi-step workflow can stop after completing only part of its work. Before retrying an entry-creation task, query the period and check what was already created. For updates, retain the target IDs and the values you intended to change so you can inspect the result.
Do not use a delete-and-recreate sequence as a routine correction strategy. Deletion removes records and may break the context you were trying to preserve. Where an edit is sufficient, update the specific entry and verify it afterwards.
Finish the weekly review with a decision
End the report with the entries that need correction, any missing query results, and the budget decisions that need an answer. Keep that list alongside the date range and rounding basis so the next weekly review can follow up on the same work.
The MCP introduction covers the underlying connection. Build automation from a report you can already reproduce manually, then add scheduling only when its inputs, output, and failure handling are understood.
