Skip to main content
Glama

Tradify: Create job

tradify_create_job

Tradify: New job for a customer. It starts as Unassigned. Creates a job for a customer. The new job starts as Unassigned until an appointment or staff is added. It reaches no one and stays inside Tradify, so it runs without asking first. Needs the user's Cotlet API key with access to this app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
referenceNoYour reference, e.g. a PO number.
customer_idYesCustomer ID from list_customers or create_customer.
descriptionYesWhat the work is.
site_addressNoJob address if different from the customer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description adds real behavior: the job starts as Unassigned until an appointment or staff is added, it notifies no one, and it requires a Cotlet API key with access. This is useful side-effect context the schema does not carry.

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

Conciseness2/5

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

The 'starts as Unassigned' fact is stated twice in near-identical sentences, and the tool name is restated as 'Creates a job for a customer' after already saying 'New job for a customer.' Multiple sentences fail to earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Safety profile is covered by annotations and the initial state and auth requirement are stated, but for a creation tool with no output schema there is no mention of what comes back (job ID, fields) or prerequisites such as the customer needing to exist first. Adequate but with clear gaps.

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 100% with four documented parameters, so the schema already does the work. The description adds no format or constraint detail (e.g., how customer_id is obtained, whether reference is required), so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Creates a job for a customer') and the object's starting state. It does not differentiate itself from siblings like tradify_create_quote or tradify_create_invoice_from_quote, so an agent must infer which creation tool applies from the name alone.

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?

Usage is implied ('New job for a customer') but there is no explicit when-to-use vs. when-not, and no direction to alternatives such as tradify_create_quote for quoting work or tradify_schedule_appointment for scheduling. An agent gets the gist but no routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources