A Jobber MCP Server: Connecting Claude to Jobber's GraphQL API

Shop owners keep hearing the same pitch: connect Claude to Jobber and ask your business questions in plain English. It has moved past talk. Shop owners are posting paid job listings right now asking for exactly this build, by name. An MCP server that connects Claude to Jobber’s GraphQL API, with plain-English questions and approved write actions. If an owner forwarded you this link, it is written for both of you.

A Jobber MCP server is a translator that lets Claude read your Jobber account and, if you allow it, act in it. MCP (Model Context Protocol) is an open standard Anthropic introduced in late 2024. A server built on it exposes tools over one standard interface. Claude connects to any server that speaks it, from the desktop app or through the API. Point the tools at Jobber’s GraphQL API and Claude can answer questions about your clients, jobs, and invoices.

We build Jobber integrations for a living and run them in production. The numbers later in this post come from that production logging. We are independent builders and not affiliated with Jobber. Our guide to connecting ChatGPT and Claude to Jobber maps all three paths, Zapier included, plus the plan gate and current pricing. This post goes one layer deeper into the server itself.

What Claude can do once it can read your Jobber account

The point of the whole exercise: ask questions the way you would ask your office manager. No clicking through nine screens for the answer. With a few read-only tools wired to your account, these become one-line questions:

• “Which clients have closed jobs and no invoice?” Claude checks jobs against invoices and lists the gaps, with amounts.
• “Summarize our history with this customer.” Every past job, quote, and payment, condensed before you return the call.
• “Which invoices are past 30 days?” Sorted oldest first, with the total at the top.
• “What did we charge on jobs like this one?” The raw material for the next quote, pulled while the customer is on the phone.

Each of those is a read. Claude looks records up, sums them, and writes the answer. Later, with approvals in place, the same chat drafts the quote or books the follow-up. You sign off before anything touches Jobber. That order matters more than any feature, and it gets its own section below.

The chat window is half the value. Owners already have it open on a phone in a truck. A question answered there in 10 seconds beats a report nobody opens.

The architecture, in three pieces

A working setup has three parts. Keeping them separate is what makes it safe to run.

1. Claude, the client. The desktop app for a person at a keyboard, or the API when questions run on a schedule.
2. The MCP server, the translator. A small program your builder writes and runs, holding the tool definitions and the Jobber connection.
3. Jobber’s GraphQL API. OAuth based, managed through Jobber’s Developer Center at developer.getjobber.com. An admin on the account authorizes your registered app. Custom API access is gated to Jobber’s Plus plan.

The line that matters for trust: the server holds the Jobber connection and decides what Claude can see and do. Claude gets tools with names and descriptions, picks one, and fills in the arguments. Everything else stays behind the wall.

MCP is a standard, so the same server outlives any one client. It works with Claude on a laptop today and with Claude over the API on a schedule tomorrow. Other MCP-speaking assistants can connect to it as they arrive.

A read-only Jobber MCP server, sketched in TypeScript

Here is a compressed sketch using Anthropic’s @modelcontextprotocol/sdk, with three read-only tools. Field names inside the GraphQL queries are simplified. The live schema is on developer.getjobber.com, and it changes, so check it before you build.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "jobber-readonly", version: "0.1.0" });

// Every Jobber call goes through this one function. It holds the
// OAuth token, tracks the query cost Jobber reports back, and checks
// each response body for a THROTTLED error, because Jobber signals
// throttling inside an HTTP 200, where status-code retry logic
// never sees it.
async function jobberQuery(query: string, variables: Record<string, unknown>) {
  // POST to Jobber's GraphQL endpoint with the stored OAuth token.
  // On THROTTLED: wait for the cost bucket to refill, then retry once.
}

server.tool(
  "find_client",
  "Look up a Jobber client by name, with contact info and address",
  { search: z.string() },
  async ({ search }) => {
    const data = await jobberQuery(FIND_CLIENT_QUERY, { search });
    return { content: [{ type: "text", text: JSON.stringify(data) }] };
  }
);

server.tool(
  "job_history",
  "List past jobs for one client: dates, status, totals",
  { clientId: z.string(), limit: z.number().max(20).default(10) },
  async ({ clientId, limit }) => {
    const data = await jobberQuery(JOBS_BY_CLIENT_QUERY, { clientId, limit });
    return { content: [{ type: "text", text: JSON.stringify(data) }] };
  }
);

server.tool(
  "overdue_invoices",
  "List unpaid invoices past their due date, oldest first",
  { minDaysOverdue: z.number().default(0) },
  async ({ minDaysOverdue }) => {
    const data = await jobberQuery(OVERDUE_INVOICES_QUERY, { minDaysOverdue });
    return { content: [{ type: "text", text: JSON.stringify(data) }] };
  }
);

Three tools, all reads. Claude sees the descriptions, picks the tool that fits the question, and calls it. The GraphQL queries are fixed, written and reviewed by whoever built the server. Claude never composes its own queries against your account. That keeps access exact and query costs predictable. The .max(20) cap on job_history is quiet load-bearing work, and the next section explains why.

The limits that shape the build

Jobber meters its API two ways at once. We measured both in production for our breakdown of Jobber’s API rate limits, with per-call cost logging. The numbers that matter here:

• A query cost budget of 10,000 points per app and account pair, refilling at 500 points per second. Every GraphQL query drains a calculated cost.
• A separate ceiling of 2,500 requests per 5 minutes.
• A reporting API does not exist. Anything report-shaped gets rebuilt from raw records through paginated queries.
• A bulk export endpoint does not exist either. Data leaves through pages, paced under the budget.
• Throttling comes back as HTTP 200 with a THROTTLED error in the body, which standard retry libraries read as success. The jobberQuery helper above parses every response for it.

For an MCP server, those numbers turn into three design rules.

Every tool call gets a cost ceiling. A question like “summarize our history with this client” fans out into paginated queries. A tool that pulls unbounded pages can drain the whole bucket on one question. So each tool caps its page size and spends a known number of points. Claude can call it again for the next page. Cost budgeting per tool call is the difference between answering all day and throttling out by 9am.

Report questions get a different data path. One of our production builds is a KPI dashboard for a Jobber shop. A single load of it measured 13,456 to 20,762 points against the 10,000 point budget. A chat question with the same shape hits the same wall. Think “give me this month’s numbers by crew.” The fix on the dashboard was a local database, synced in the background and paced under the refill rate. A heavy report tool needs the same store behind it. Save the live queries for the small lookups.

Design for a fast first answer. A big paginated pull takes real seconds under a 500 point per second refill. Good tools return a tight first page plus a count of what remains. The owner gets an answer now, and Claude offers to keep digging.

Read-only first, approved actions later

Every conversation about AI on a Jobber account reaches the same worry within minutes: what if it changes something? The answer is a structure with two stages. The shops hiring for this work are specifying the same order themselves. One hiring post put it plainly: start read-only, add write-back only after the recommendations prove accurate.

Stage 1 is read-only, and a read-only server cannot break anything in Jobber. The tools can look, count, and summarize. The worst failure is a wrong answer. You catch those the way you would with a new office hire. Check the first few weeks of output against Jobber’s own screens before you lean on it.

Stage 2 adds write actions, one at a time, each behind an explicit approval step. Draft-a-quote is the usual first one. Claude drafts, and the draft lands in front of a person. The approval is what triggers the server to write to Jobber. A log records who approved what, and when. A setup that sends invoices or reschedules visits with nobody in the loop is one we decline to build.

This staged structure is the spine of our Jobber AI service: read-only tools first, then write actions as each one earns its approval step.

Three ways to get AI answers from Jobber

The honest read of that table: start with the cheapest row that covers your question list. Check what AI Jobber has shipped on your plan before paying anyone. The custom row exists for the questions the first two rows cannot reach. Your definitions, your cross-record math, your approval rules.

When a Jobber MCP server is the wrong buy

• Your questions are small. If “who owes me money” is answered by opening the invoices screen, keep opening it. A build has to beat a bookmark.
• Your wish list is trigger-action. “When a job closes, draft a review request” is Zapier work. Our AI-to-Jobber guide covers that path, and it runs without the Plus plan.
• You are on a lower Jobber plan with no plans to move. Custom API access is gated to Plus. The plan math in that same guide comes first in any honest scoping.
• You want one report, once. Pay a builder to pull it. A standing server earns its cost when the questions repeat, cross records, and come from more than one person.

If you are scoping one

We build Jobber integrations in production. An MCP server is the same API discipline with a conversational front end: staged the way described here, rate-limit design in from day one. Our Jobber AI page covers what a build includes and where it starts. Or book a discovery call and bring the three questions you most wish Jobber could answer. If Zapier or a plain export covers them, you will hear that in the first fifteen minutes.