Skip to main content
Glama
montrellcruse

ServiceTitan MCP

by montrellcruse
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

intel_lookup

Read-onlyIdempotent

Resolve reference data for intelligence-tool filters: search technicians, business units, payment types, or membership types by name and get matching IDs.

Instructions

Look up technicians, business units, payment types, or membership types for use in intelligence-tool filters. Returns matching IDs and names from a 30-minute in-process cache; search performs a case-insensitive name match, while omission returns the available cached set.

Examples:

  • "What are our business units?" -> type="business-units"

  • "Find technician named John" -> type="technicians", search="John"

  • "List all payment types" -> type="payment-types"

  • "What membership types do we have?" -> type="membership-types"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesType of reference data to look up
searchNoSearch by name (partial match). Omit to list all.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {},
+  "type": "object"
+}
  2. First observedv2.5.1

TDQS

A4.7/5.0
Behavior5/5

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

The annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond that: results come from a 30-minute in-process cache, matching is case-insensitive, search is a partial name match, and omitting search returns the full cached set. This gives an agent accurate expectations about freshness and matching behavior.

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 well-structured: the core behavior and purpose come first, followed by a concise cache/freshness statement, then four crisp examples that map naturally phrased questions to parameter values. No sentence is wasted.

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?

The tool is simple (two parameters, one enum) and has an output schema, so the description does not need to describe return fields. It covers accepted types, search behavior, cache behavior, and example invocations, which is sufficient for an agent to select and call it correctly.

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?

Input schema coverage is 100%, so the schema already documents both parameters. The description adds value with concrete natural-language-to-parameter examples and the behavior detail that matching is case-insensitive, which is not in the schema. It reinforces rather than merely repeats the schema.

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 ('Look up') and explicitly names the four resource types it covers, plus the purpose ('for use in intelligence-tool filters'). The examples reinforce the intended scope and make it clearly distinct from the many list/report siblings.

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

Usage Guidelines4/5

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

The description clearly states that this tool returns filter candidates for intelligence tools and demonstrates how to phrase requests for each type. It does not explicitly name alternatives or exclusions, but the 'for use in intelligence-tool filters' framing gives enough contextual guidance for an agent to choose it over export/list siblings.

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

Deploy Server

Other Tools