ServiceTitan MCP

dispatch_installed_equipment_list

Read-onlyIdempotent

Search installed equipment records by IDs, location IDs, active status, or created/modified date ranges to get a paginated list for review or follow-up.

Instructions

Search installed-equipment records by IDs, location IDs, active state, or created and modified ranges. Returns one page; use dispatch_installed_equipment_get for a known ID.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ids`	No	Comma-separated installed equipment 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
`pageSize`	No	Records per page (default 50)
`locationIds`	No	Comma-separated location IDs to include
`includeTotal`	No	Include total count in response
`createdBefore`	No	Return items created before this UTC timestamp
`modifiedBefore`	No	Return items modified before this UTC timestamp
`createdOnOrAfter`	No	Return items created on or after this UTC timestamp
`modifiedOnOrAfter`	No	Return items modified on or after this UTC timestamp

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?

The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's additional disclosure that it 'returns one page' is valuable behavioral context beyond the structured metadata. It also implicitly warns against expecting a full dataset in a single call, which is useful for agent planning.

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. It front-loads the core purpose and search dimensions, then ends with the necessary pagination caveat and sibling routing. 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?

With an output schema present and comprehensive parameter descriptions in the schema, the description covers the essential selection and invocation context: what it searches, that it is paginated, and when to prefer the get variant. It lacks explicit guidance about bulk export alternatives, but that is a minor gap given the tool's clear search orientation.

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?

The input schema has 100% description coverage, so the schema carries the parameter meaning. The description restates the main filter categories but adds no syntax, defaults, or format details beyond what the schema already provides. This meets the baseline for well-documented schemas.

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 clearly states the tool searches installed-equipment records with specific filter dimensions (IDs, location IDs, active state, created/modified ranges). It also names the sibling dispatch_installed_equipment_get for known-ID lookups, so an agent can distinguish them without inspecting schemas.

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 explicitly directs the agent to use dispatch_installed_equipment_get when a known ID is available, which is a precise when-not-to-use-this-tool signal. It also frames this tool as a search-and-paginate operation, making its role among the sibling list tools clear.

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

Deploy Server