Skip to content

Connect Jobber to ChatGPT: Manage Leads, Requests and Job Status

Learn how to connect Jobber to ChatGPT using a managed MCP server. Execute workflows for clients, work requests, and job scheduling using natural language.

Yuvraj Muley Yuvraj Muley · · 9 min read

If you need to connect Jobber to ChatGPT to automate field service operations, qualify inbound leads, or query open work requests, you need a Model Context Protocol (MCP) server. This infrastructure layer acts as the translator between ChatGPT's tool calling capabilities and Jobber's complex API endpoints. You can spend weeks building, hosting, and maintaining this server yourself, or you can use a managed platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses Claude, check out our guide on connecting Jobber to Claude or explore our broader architectural overview on connecting Jobber to AI Agents.

Giving a Large Language Model (LLM) read and write access to a specialized field service platform like Jobber is an engineering challenge. You have to handle a hybrid of REST and GraphQL API structures, respect strict rate limits without infinite retries, and navigate Jobber's rigid workflow state machines. Every time Jobber introduces a new field or updates their schema, custom integration code must be refactored and redeployed.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Jobber, connect it natively to ChatGPT, and execute complex field service workflows using natural language.

Stop writing boilerplate API integration code. Let Truto generate secure, managed MCP servers for your AI agents in seconds. :::

The Engineering Reality of the Jobber API

Building a custom MCP server is essentially building a self-hosted integration middleware. While the open MCP standard provides a predictable JSON-RPC format for models to discover tools, implementing it against Jobber's specific API quirks is painful. If you build this in-house, you own the entire integration lifecycle.

Here are the specific engineering challenges you face when connecting an AI agent to Jobber:

The Hybrid REST and GraphQL Divide

Jobber exposes basic CRUD operations through standard REST-like endpoints, but complex relational operations, custom fields, and detailed line-item management rely heavily on their GraphQL API. A naive MCP server that only maps REST endpoints will leave your LLM unable to update a client's status tags or attach multiple line items to a quote. Your integration layer must expose basic tools for scalar reads, alongside a flexible GraphQL passthrough tool so the LLM can construct complex mutations when necessary.

Workflow-Driven State Machines

In standard SaaS tools, updating a status is usually a simple PATCH request with a new string value. Jobber does not work this way. A requestStatus or jobStatus is a derived property. You cannot simply instruct an API to "change the request status to completed." The status is strictly driven by the underlying workflow - a request becomes completed when a quote is drafted and approved, or a job is scheduled. If an LLM tries to hallucinate a direct status update, Jobber will reject the payload.

Strict Rate Limiting and Backoff

Jobber enforces strict API rate limits to protect their infrastructure. When an AI agent performs aggressive data gathering - like paginating through hundreds of historical jobs to generate a report - it will hit these limits quickly.

It is critical to understand how this is handled structurally: Truto does not retry, throttle, or apply backoff on rate limit errors. When the Jobber API returns an HTTP 429 Too Many Requests, Truto passes that error directly back to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) following the IETF specification. The caller (your LLM client or agent orchestration framework) is entirely responsible for reading these headers and implementing the necessary retry and backoff logic. Do not assume your MCP server will absorb these errors for you.

Step-by-Step Guide: Connecting Jobber to ChatGPT

To connect Jobber to ChatGPT, you need to authenticate a Jobber account, generate an MCP server configured for that account, and register the endpoint with your client. Truto handles the OAuth credential lifecycle, meaning ChatGPT will never see an expired token.

Step 1: Connect Jobber as an Integrated Account

First, navigate to the Truto dashboard and create a new Integrated Account for Jobber. Complete the OAuth flow as an administrator. Once connected, Truto securely stores the refresh token and manages the token refresh cycles in the background.

Grab your integrated_account_id from the dashboard or via the API. This ID scopes the MCP server to this specific tenant.

Step 2: Generate the Jobber MCP Server URL

Truto dynamically generates MCP tools based on Jobber's API documentation. You must create a server endpoint scoped to your integrated account. You can do this in two ways.

Method A: Via the Truto UI

  1. Navigate to the Integrated Account page for your Jobber connection in the Truto dashboard.
  2. Click the MCP Servers tab.
  3. Click Create MCP Server.
  4. Select your desired configuration (name, method filters, tags, and expiration).
  5. Copy the generated MCP server URL (formatted as https://api.truto.one/mcp/<token>). Treat this URL as a sensitive credential.

Method B: Via the API You can programmatically provision a server using the Truto API. This is ideal for multi-tenant applications dynamically assigning AI agents to different field teams.

curl -X POST https://api.truto.one/integrated-account/$INTEGRATED_ACCOUNT_ID/mcp \
  -H "Authorization: Bearer $TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Jobber Lead Automation Agent",
    "config": {
      "methods": ["read", "write", "custom"],
      "tags": ["clients", "requests", "jobs"]
    }
  }'

The API returns a JSON payload containing the url.

Step 3: Connect the MCP Server to ChatGPT

Now that you have the active MCP server URL, you must instruct your client to use it.

Method A: Via the ChatGPT UI (For Enterprise/Pro Users) If you are using a ChatGPT Pro, Plus, Business, Enterprise, or Education account, you can plug this directly into the interface.

  1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
  2. Ensure Developer mode is enabled.
  3. Under MCP servers / Custom connectors, click to add a new server.
  4. Enter a descriptive name (e.g., "Jobber Operations").
  5. Paste the Truto MCP URL into the Server URL field and click Add.

ChatGPT will immediately perform the initialization handshake and discover the available Jobber tools.

Method B: Via Manual Configuration File (For custom clients or Cursor/Claude Desktop) If you are using a local agent framework, Cursor, or building a custom app, you can use the official @modelcontextprotocol/server-sse transport wrapper to connect to Truto's remote endpoint. Your configuration JSON typically looks like this:

{
  "mcpServers": {
    "jobber_automation": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/YOUR_SECURE_TOKEN"
      ]
    }
  }
}

Jobber Hero Tools for ChatGPT

Truto automatically generates highly specific tools for the Jobber API based on available endpoints and schemas. Instead of generic CRUD, the LLM receives schemas optimized for function calling.

Here are 6 high-leverage tools available for your agent.

1. list_all_jobber_clients

This tool retrieves a paginated list of Jobber clients. It returns scalar data like name, isLead, email, and balance, along with vital rollups like jobs.totalCount and requests.totalCount. You can pass filters like {"isLead": true} to restrict the search. An LLM can easily identify clients who have never had work booked by checking if jobs.totalCount is 0.

"Find all clients in Jobber flagged as leads who have zero total jobs booked. I want to see who hasn't converted yet."

2. create_a_jobber_client

Used to lodge a qualifying lead or add a new customer to the database. The tool accepts scalar fields for the primary record. By default in Jobber, new clients start with isLead set to true.

"Create a new client profile for Sarah Jenkins. She's a new inbound lead calling about roof repair."

3. list_all_jobber_requests

Retrieves incoming work enquiries and their statuses. It returns the request title, requestStatus, contactName, and associated totals. Filtering by {"status": "new"} allows an agent to build a queue of unhandled leads.

"Pull a list of all Jobber requests that currently have the status 'new' so I can draft follow-up emails."

4. create_a_jobber_request

Creates a new work enquiry against an existing client. This requires passing the client_id in the body. The resulting request will automatically have the requestStatus set to "new" by Jobber's internal logic.

"Create a new work request for client ID 4591. The title should be 'Emergency Plumbing Assessment'."

5. list_all_jobber_jobs

Queries the actual booked work in the system. It returns jobNumber, jobStatus, total, and crucial scheduling timestamps. This is the primary tool an LLM uses to verify if a service was successfully delivered and billed.

"Look up the recent jobs for the past 30 days and list the ones where the job status is currently active or scheduled."

6. create_a_jobber_graphql

This is the critical escape hatch tool. Because Jobber relies on GraphQL for complex operations, this tool allows the LLM to execute arbitrary GraphQL queries or mutations. If the agent needs to set custom status tags (via clientEdit), configure detailed line items, or manage complex custom fields, it constructs the payload here.

"Using the GraphQL tool, run a clientEdit mutation to add the 'VIP Customer' tag to client ID 8902 and update their secondary phone number."

For the complete inventory of available Jobber operations - including pagination schemas, archive endpoints, and webhook configurations - view the full Jobber integration reference.

Workflows in Action

When you combine these tools, ChatGPT stops being a simple chatbot and becomes a fully capable operations assistant. Here are two real-world workflows.

Scenario 1: Lead Qualification and Request Creation

User Prompt:

"Check if we have an existing client named 'Acme Corp'. If they exist, see if they have any open requests. If they don't have open requests, create a new request for 'Annual HVAC Maintenance'."

Execution Steps:

  1. list_all_jobber_clients: The agent searches for "Acme Corp". It parses the response, locating the client ID and viewing their requests.totalCount.
  2. list_all_jobber_requests: The agent queries requests filtered by the discovered client ID to verify none are currently in a "new" or "unscheduled" state.
  3. create_a_jobber_request: Confirming no open requests exist, the agent calls this tool, passing the client ID and the title "Annual HVAC Maintenance".

Outcome: The user receives confirmation that Acme Corp was found, had zero active requests, and a new work request was successfully lodged in the dispatch queue.

sequenceDiagram
  participant User as User Prompt
  participant ChatGPT as ChatGPT (MCP Client)
  participant Truto as Truto MCP Server
  participant Jobber as Jobber API

  User->>ChatGPT: "Check Acme Corp and draft HVAC request"
  ChatGPT->>Truto: list_all_jobber_clients (search: Acme Corp)
  Truto->>Jobber: GET /clients?search=Acme+Corp
  Jobber-->>Truto: Returns client ID 8492
  Truto-->>ChatGPT: Parsed client schema
  ChatGPT->>Truto: list_all_jobber_requests (client_id: 8492)
  Truto->>Jobber: GET /requests?client_id=8492
  Jobber-->>Truto: Returns empty array
  Truto-->>ChatGPT: Zero open requests
  ChatGPT->>Truto: create_a_jobber_request (client_id: 8492)
  Truto->>Jobber: POST /requests
  Jobber-->>Truto: 201 Created (Request ID 551)
  Truto-->>ChatGPT: Success schema
  ChatGPT-->>User: "New HVAC request created for Acme Corp."

Scenario 2: Auditing Stale Work Enquiries

User Prompt:

"Find all leads that have a new work request older than 7 days, and summarize their contact information so I can call them."

Execution Steps:

  1. list_all_jobber_requests: The agent fetches requests filtered by {"status": "new"}.
  2. It inspects the createdAt timestamps in the payload to isolate requests older than 7 days.
  3. get_single_jobber_client_by_id: For each stale request, the agent extracts the associated client ID and fetches their full profile to grab the most up-to-date phone number and email address.

Outcome: The operations manager receives a bulleted call list of highly qualified, aging leads with direct contact details, without ever opening the Jobber dashboard.

Security and Access Control

Exposing an ERP or field service platform to an autonomous AI requires strict access constraints. Truto's MCP servers provide granular configuration controls at the token level, ensuring the agent only touches what it is supposed to.

  • Method Filtering (config.methods): Restrict the server to specific operation types. For a reporting agent, setting methods: ["read"] ensures the LLM can only execute list and get operations, physically blocking it from creating or deleting jobs.
  • Tag Filtering (config.tags): Group tools by domain. By configuring a token with tags: ["requests"], the server will only expose request-related endpoints, hiding payroll or deeper client financial data from the prompt context.
  • API Token Auth (require_api_token_auth): By default, the MCP URL acts as a bearer token. For higher security, enabling this flag forces the client to also provide a valid Truto API session token, ensuring only authenticated human users can trigger the underlying tools.
  • Time-To-Live (expires_at): Ideal for temporary agent sessions. You can set an exact ISO datetime for the server to self-destruct. Truto utilizes distributed cleanup alarms to purge the cryptographic token from the secure key-value storage exactly at expiration, instantly terminating access.

Empowering Field Service AI

Connecting Jobber to ChatGPT bridges the gap between field operations and conversational intelligence. By utilizing an auto-generated, managed MCP server, engineering teams can bypass the complexities of API schema drift, OAuth token refreshes, and rate limit header parsing.

Instead of maintaining fragile boilerplate integration code, your team can focus on orchestrating complex dispatch workflows, qualifying leads instantly, and building powerful internal tooling for your operations staff.

FAQ

How do I handle Jobber API rate limits with an MCP server?
Truto passes standard IETF rate limit headers directly to the client. The MCP server does not absorb or retry failed requests. Your LLM client or orchestration framework must implement proper backoff logic based on the returned headers.
Can ChatGPT update a Jobber request status directly?
No. Jobber statuses are workflow-driven. You cannot send a simple string update to change a status to 'completed'. You must advance the underlying entities (like converting a quote to a job) to trigger status changes.
Does Truto support Jobber GraphQL operations via MCP?
Yes. While standard scalar operations are mapped to simple tools, the create_a_jobber_graphql tool acts as an escape hatch, allowing the LLM to construct and send raw GraphQL queries for complex line items and custom fields.
How do I restrict what ChatGPT can do in Jobber?
You can use Truto's MCP token configuration to apply method and tag filters. For example, restricting methods to 'read' ensures the LLM can only query data and cannot create or modify Jobber records.

More from our Blog