Skip to main content
Glama
Sign In
Tradify MCP server

Tradify MCP server

by cotletdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get customer

get_customer
Read-onlyIdempotent

Retrieve a customer's profile with contact details, sites, notes, latest jobs, quotes, invoices, and balance due to review account activity and amounts owed.

Instructions

Customer profile with sites, notes, latest jobs, quotes and invoices, and the balance due.

Returns one customer: contact, email, phone, address, sites and notes, plus the latest 25 jobs, quotes and invoices with their totals (job_count, quote_count and invoice_count give the full numbers; list_jobs, list_quotes and list_invoices page through more). balance_due adds up what is due on the approved invoices returned.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "customer_id": "<customer_id>"
    },
    "name": "get_customer"
  }
}

Input Schema

NameRequiredDescriptionDefault
customer_idYesCustomer ID from list_customers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.3

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuine behavioral detail beyond them: the embedded collections are truncated at 25 items, the counts are full totals, and balance_due is computed only from approved invoices returned — a non-obvious caveat. It doesn't cover error behavior for an unknown customer_id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded summary sentence followed by a paragraph detailing collections and totals; every sentence carries information. The opening sentence partially duplicates the detail sentence's field list, which is minor redundancy.

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 no output schema, the description does the heavy lifting by describing the return shape, the 25-item truncation, the count fields and balance_due semantics. Only the not-found/error path is left unstated, which is a small gap for a simple single-ID read.

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?

There is one parameter at 100% schema coverage, so the schema already documents customer_id as coming from list_customers. The description adds nothing about the identifier format or lookup failure, so baseline 3 applies.

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?

States a concrete verb+resource (returns one customer) and enumerates the exact payload: contact, email, phone, address, sites, notes, latest 25 jobs/quotes/invoices, and balance_due. The scoping to a single record cleanly separates it from list_customers.

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?

Explicitly routes the agent to list_jobs, list_quotes and list_invoices when it needs to page beyond the embedded 25 records, and clarifies that job_count/quote_count/invoice_count give true totals. It doesn't state when to prefer this over list_customers or get_invoice for an individual record, but the context is clear.

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