ServiceTitan MCP

memberships_custom_fields_list

Read-onlyIdempotent

Retrieve a page of membership custom-field definitions, with filters for created or modified timestamps. Returns metadata about custom fields used on membership records.

Instructions

List one requested page of membership custom-field definitions using created and modified timestamp filters. Use this for field metadata; use memberships_list for customer membership records and their field values.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number (starts at 1)
`sort`	No	Sort: Field (default), +Field (asc), or -Field (desc). Fields: Id, Name, CreatedOn, ModifiedOn
`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.7/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. On top of that, the description adds behavioral context: each call returns a single requested page and supports created/modified timestamp filters, which is useful beyond the basic safety profile. 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?

Two sentences, no filler, with the core operation front-loaded and the sibling distinction in the second sentence. Every clause earns its place.

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 an optional-parameter read-only list endpoint with an output schema and safety annotations, this is complete: it states pagination, filters, resource type, and the right alternative. The schema handles default page size, sort fields, and output shape, so the description does not need to repeat them.

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?

With only 50% schema description coverage, the timestamp parameters are otherwise undocumented; the description gives them collective meaning as 'created and modified timestamp filters' and clarifies the pagination intent with 'one requested page.' It does not spell out before/on-or-after boundary semantics, but the parameter names and date-time format carry most of that load.

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 membership custom-field definitions' — this is a paginated metadata-listing operation, not a record read. It also distinguishes itself from memberships_list, so an agent can tell the two apart immediately.

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?

It gives explicit selection criteria: 'Use this for field metadata; use memberships_list for customer membership records and their field values.' This names the closest alternative and states exactly when each tool is appropriate, with no inference required.

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

Deploy Server