ServiceTitan MCP

crm_locations_notes_list

Read-onlyIdempotent

Retrieve paginated notes for a service location by ID, with optional timestamp filters for created or modified dates.

Instructions

List one page of notes attached to a known service location, optionally filtered by created or modified timestamps. Requires the location ID.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Location ID
`page`	No	Page number (starts at 1)
`pageSize`	No	Records per page (default 50)
`includeTotal`	No	Include total count in response
`createdBefore`	No
`modifiedBefore`	No
`createdOnOrAfter`	No
`modifiedOnOrAfter`	No

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

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral details beyond those: it returns only one page of notes, can be filtered by created or modified timestamps, and requires a known location ID. It does not contradict the 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?

The description is two short sentences with no redundant wording. It front-loads the primary purpose, then adds the key prerequisite. 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?

For a read-only list tool with comprehensive annotations and an output schema, the description covers the essential operational context: what is listed, pagination scope, optional filters, and the required location ID. It could additionally have mentioned the timestamp parameter names, but the schema and intuitive naming largely fill that gap.

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 50%, leaving the four date-time filter parameters undocumented in the schema. The description partially compensates by noting that filtering is by 'created or modified timestamps,' which groups those parameters semantically. However, it does not explain before/on-or-after semantics or the pagination parameters beyond what the schema already provides.

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 uses a specific verb ('List') with a precise resource ('notes attached to a known service location') and states the core behavior: one page, optional timestamp filters. It clearly distinguishes this from sibling note-list tools by anchoring to service locations and requiring a location ID.

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

Usage Guidelines3/5

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

The description implies when to use it: when the target is a service location and you have its ID. It also states a clear prerequisite ('Requires the location ID'). However, it does not explicitly contrast this with sibling tools like crm_customers_notes_list or crm_leads_notes_list, nor does it mention when not to use it.

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

Deploy Server