ServiceTitan MCP

inventory_transfers_list

Read-onlyIdempotent

Search and list inventory transfers between locations using filters like status, transfer type, source and destination locations, dates, and sync status.

Instructions

List one requested page of inventory transfers using IDs, number, status, transfer type, source and destination locations, dates, sync status, and external-data filters. Use this for stock moved between locations; use inventory_returns_list for stock returned to a vendor.

Input Schema

TableJSON Schema

Name	Required	Description
`ids`	No	Comma-separated transfer IDs (maximum 50)
`page`	No	Page number (starts at 1)
`sort`	No	Sort: Field (default), +Field (asc), or -Field (desc). Fields: Id, ModifiedOn, CreatedOn
`number`	No	Transfer number filter
`batchId`	No	Batch ID filter
`pageSize`	No	Records per page (default 50)
`statuses`	No	Comma-separated transfer statuses
`dateBefore`	No	Transfer date before this UTC timestamp
`includeTotal`	No	Include total count in response
`syncStatuses`	No	Comma-separated sync statuses
`createdBefore`	No
`dateOnOrAfter`	No	Transfer date on or after this UTC timestamp
`toLocationIds`	No	Comma-separated to-location IDs
`modifiedBefore`	No
`externalDataKey`	No	External data key
`fromLocationIds`	No	Comma-separated from-location IDs
`referenceNumber`	No	Reference number filter
`transferTypeIds`	No	Comma-separated transfer type IDs
`createdOnOrAfter`	No
`modifiedOnOrAfter`	No
`customFieldsFields`	No	Custom field name/value filters
`externalDataValues`	No	External data values
`customFieldsOperator`	No	Operator for custom field filters
`externalDataApplicationGuid`	No	External data application GUID

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

Behavior4/5

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

Annotations already declare the tool read-only, idempotent, non-destructive, and open-world. The description adds the single-page behavior ('one requested page') and lists the filter families, which is useful beyond the annotations. It does not discuss auth or response defaults, but those are less critical given the annotations and output schema.

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 two sentences with no filler. The core action and scope are front-loaded, and the second sentence efficiently provides a routing rule for a closely related sibling tool.

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?

Given 24 optional parameters, a rich schema, an output schema, and safety annotations, the description provides solid orientation: what the tool lists, how pagination behaves, the main filter families, and when to choose the sibling returns tool. It does not mention bulk-export alternatives like export_transfers or custom-field filters, but the schema fills those gaps.

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%, so the schema already documents most parameters. The description condenses the many filters into broad categories such as status, transfer type, locations, dates, and external data, but it adds little detail beyond the schema and omits custom-field filters. This is adequate but not a strong value-add.

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 resource: 'List one requested page of inventory transfers.' It also enumerates the main filter dimensions and explicitly distinguishes the tool from inventory_returns_list, so an agent can clearly tell what this tool does and what it is not for.

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 direct, actionable usage guidance: use this tool for stock moved between locations, and use inventory_returns_list when stock is returned to a vendor. This is an explicit when/when-not statement with a named alternative.

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

Deploy Server