Skip to main content
Glama

Get report

get_report
Read-onlyIdempotent

Run one Tradify report for a date range and return rows for job profitability, job sheets, staff productivity, or timesheets to review costs, invoices, schedules, and logged hours.

Instructions

Job profitability, job sheet, staff productivity or timesheet report for a period, as rows.

Runs one report of Tradify's Reports page for the days from to to (both included, at most a year) and returns the rows of its CSV download, amounts as numbers. job_profitability gives three rows per job (Time, Materials, Total) with estimated cost from quotes, actual cost, invoiced, to invoice, gross profit and margin. job_sheet lists the jobs with site, staff, schedule, contacts, entered by and on. staff_productivity gives billable, non-billable and total hours (h:mm) per staff member. timesheets lists each time entry with job, customer, staff member, billing rate, notes, date and hours. date_basis picks jobs by entry or by schedule date. Stops at 1000 rows with truncated true.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "report": "<report>",
      "from": "<from>",
      "to": "<to>"
    },
    "name": "get_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesLast day of the period, up to a year after from.
fromYesFirst day of the period.
staffNoOnly this staff member, by full name.
reportYesjob_profitability (estimated and actual cost, invoiced, to invoice, gross profit and margin per job, split into time and materials), job_sheet (jobs with site, staff, schedule, contacts, labour and cost), staff_productivity (billable and non-billable hours per staff member) or timesheets (time logged per job and staff member).
date_basisNojob_profitability and job_sheet: jobs entered in the period (default) or scheduled in it.entered
customer_idNojob_profitability, job_sheet, timesheets: only this customer (list_customers).
include_inactive_jobsNojob_sheet: also complete and cancelled jobs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.3

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare this as a safe, read-only, idempotent operation. The description adds substantial behavioral context: CSV-style rows, numeric amounts, a maximum one-year period, a 1000-row truncation limit, and the shape of each report's output.

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 front-loaded with the core action and then enumerates report types and filters efficiently. It is somewhat long and repeats some enum details from the schema, but the density is reasonable for a seven-parameter multi-report 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?

There is no output schema, so the description carries the return-value burden. It adequately explains report row contents, date limits, filtering constraints, and truncation behavior, which is enough for an agent to invoke the tool correctly.

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%, so all parameters are already documented. The description mostly restates report contents and filter behavior already present in the schema, adding little new parameter-specific semantics beyond the row-limit and numeric-amount output notes.

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

Purpose4/5

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

The description states a specific resource and action: runs one of four named Tradify reports for a date range and returns rows. It makes the four report types distinguishable, but it does not explicitly differentiate this tool from nearby siblings such as list_timesheets.

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

Usage Guidelines4/5

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

It gives clear context for choosing among the four report values and explains filters such as date_basis, customer_id, and include_inactive_jobs. It does not explicitly state when to use get_report instead of overlapping list tools like list_timesheets.

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