ServiceTitan MCP

inventory_receipts_list

Read-onlyIdempotent

List inventory receipt transactions using filters such as vendor, purchase order, bill, business unit, location, and received date to track incoming stock.

Instructions

List one requested page of inventory receipt transactions using IDs, number, vendor, purchase order, bill, business unit, inventory location, sync status, and received-date filters. Use inventory_purchase_orders_list for originating orders and inventory_returns_list for outbound vendor returns.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ids`	No	Comma-separated receipt IDs (maximum 50)
`page`	No	Page number (starts at 1)
`sort`	No	Sort: Field (default), +Field (asc), or -Field (desc). Fields: Id, ModifiedOn, CreatedOn
`active`	No	Filter by active status	True
`billId`	No	Bill ID filter
`number`	No	Receipt number filter
`batchId`	No	Batch ID filter
`pageSize`	No	Records per page (default 50)
`vendorIds`	No	Comma-separated vendor IDs
`includeTotal`	No	Include total count in response
`syncStatuses`	No	Comma-separated sync statuses
`createdBefore`	No
`modifiedBefore`	No
`receivedBefore`	No	Received-on timestamp upper bound
`businessUnitIds`	No	Comma-separated business unit IDs
`createdOnOrAfter`	No
`purchaseOrderIds`	No	Comma-separated purchase order IDs
`modifiedOnOrAfter`	No
`receivedOnOrAfter`	No	Received-on timestamp lower bound
`customFieldsFields`	No	Custom field name/value filters
`vendorInvoiceNumber`	No	Vendor invoice number filter
`customFieldsOperator`	No	Operator for custom field filters
`inventoryLocationIds`	No	Comma-separated inventory location IDs

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.0.0Sep 6, 2026

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.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the pagination trait ('one requested page') and available filter dimensions, which is useful but not rich behavioral context such as default ordering or response envelope behavior. No contradiction with annotations.

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?

Two sentences with zero filler. Purpose and filter scope are front-loaded in the first sentence; sibling routing is in the second. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a list tool of this complexity: annotations carry the safety profile, an output schema documents return values, and the description covers purpose, pagination, filters, and sibling routing. Minor omissions (default sort behavior, custom-field filtering capability) are already documented in the schema, so nothing essential for correct invocation is missing.

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 83% (>80%), so baseline 3 applies with the schema carrying the detail. The description adds a concise high-level grouping of filter categories (IDs, number, vendor, purchase order, bill, business unit, inventory location, sync status, received-date) that maps onto the schema params, but provides no syntax or format details beyond what the schema already documents.

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 states a specific verb ('List'), a specific resource ('inventory receipt transactions'), and the pagination scope ('one requested page'). It enumerates the filter dimensions and names sibling tools it is not (inventory_purchase_orders_list, inventory_returns_list), so an agent can distinguish it without opening the schema.

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?

Provides explicit routing: 'Use inventory_purchase_orders_list for originating orders and inventory_returns_list for outbound vendor returns.' This tells the agent exactly when NOT to use this tool and which sibling to select instead, leaving nothing to inference.

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

Deploy Server