ServiceTitan MCP

reporting_reports_data_create

Read-onlyIdempotent

Retrieve a specific page of report data from ServiceTitan by supplying report category, ID, and required parameters. Use page, pageSize, and includeTotal to control pagination and totals.

Instructions

Execute one requested page of a known report and return the upstream report-data response. First inspect reporting_reports_get for that report's required parameter names, value types, and accepted formats; pass those entries in parameters, and use page, pageSize, and includeTotal to control this request. This generic reporting call is not subject to the intelligence tools' report scheduler or 65-second spacing.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number (starts at 1)
`pageSize`	No	Records per page
`reportId`	Yes	Report ID
`parameters`	Yes	Report parameters (name/value pairs from report definition)
`includeTotal`	No	Include total count
`reportCategory`	Yes	Report category ID

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv3.0.0Sep 6, 2026

changedInput schema / properties / parameters / items / properties / value / description

Previous value: -"Parameter value"New value: +"Parameter value, using the data type declared by the report definition"

removedInput schema / properties / parameters / items / properties / value / type
```
Removed value: -"string"
```

changedInput schema / properties / parameters / items / required

Previous value: -[
-  "name",
-  "value"
-]New value: +[
+  "name"
+]

changedInput schema / required

Previous value: -[
-  "reportCategory",
-  "reportId"
-]New value: +[
+  "reportCategory",
+  "reportId",
+  "parameters"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {},
+  "type": "object"
+}

First observedv2.5.1Apr 18, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (read-only, idempotent, open-world, non-destructive). The description adds meaningful behavioral context beyond that: it returns the upstream report-data response, executes only one requested page, and is exempt from the intelligence tools' scheduling constraints. No contradiction with annotations is present.

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 three sentences with no filler: it states the core action, gives the parameter workflow, and notes a key distinction from sibling tools. Each sentence earns its place and the most important information 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?

For a generic report-data execution call with an output schema, the description covers the prerequisites (known report, inspect reporting_reports_get), parameter sourcing, pagination controls, and relevant scheduler distinction. The output schema handles return-value details, and annotations cover the behavioral safety profile, so nothing essential 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 100%, so the baseline is 3, but the description adds value by explaining how to populate parameters: look up required parameter names, value types, and accepted formats from reporting_reports_get, then pass them as name/value entries. It also clarifies the roles of page, pageSize, and includeTotal as request controls, going beyond the schema's per-property descriptions.

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 opens with a specific verb and object: 'Execute one requested page of a known report and return the upstream report-data response.' It clearly identifies the tool's resource (a page of a known report) and distinguishes it from the related reporting_reports_get and the intelligence tools by noting it is a generic reporting call not bound to their scheduler or spacing.

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?

The description gives explicit when-to-use guidance: first inspect reporting_reports_get for parameter definitions, then pass those entries in parameters and control the request with page, pageSize, and includeTotal. It also tells the agent how this call differs from the intelligence tools by explicitly stating it is not subject to the report scheduler or 65-second spacing.

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

Deploy Server