How do I use BackCrew Jobber MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BackCrew Jobber MCP Server show me my open jobs" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

BackCrew Jobber MCP Server

by jayson-svg

Overview Schema Related Servers Score Discussions

TypeScript

BackCrew Jobber MCP Server

Think of this like a brand-new employee on their first day, not a business partner. A new hire only does the exact tasks you've shown them, nothing more, until you decide they're ready for more responsibility.

It lets you connect an AI assistant like Claude or ChatGPT to your Jobber account, so you can ask for things in plain English ("find this client," "what jobs are open") instead of clicking through the Jobber app yourself. On day one, it only knows how to look things up. You decide if and when to train it up to doing more.

Built by BackCrew, part of a series of free tools like this for the software pest control companies use every day.

Not a developer? That's fine. Everything up through "Testing it safely" is written for you, no coding background needed.
Read this first: this is the most limited repo in the series, and for a specific reason explained below. Jump to Why this one is smaller and more cautious than our other repos.

Related MCP server: Jobber MCP Connector

What this actually does

Let's be upfront about what this is, because it's easy to oversell: this is not an all-knowing office assistant that understands your business and handles things for you. It's a specific, listed set of actions that an AI assistant is allowed to trigger when you ask for them in plain English. The AI doesn't have judgment about your business; it matches what you ask for to the closest action on its list and does exactly that, nothing more.

Why use an independent MCP server instead of the platform's own AI?

Software platforms are increasingly shipping their own built-in AI features. Worth knowing why you might still reach for this instead:

No plan-tier gates. Native AI features are often locked to a platform's most expensive plan. This project just needs API access, which is usually available on lower tiers too.
Cross-platform, not walled off. A platform's own AI only sees that platform's own data; it has no reason to work fluently with your accounting software, another CRM, or your email, since those are somebody else's product. An MCP-connected assistant can have multiple servers attached at once (this one plus another BackCrew server covering a different part of your business), so it can work across your whole stack in one conversation.
Your choice of AI, not theirs. You keep using whichever assistant you already trust (Claude, ChatGPT, whatever) instead of learning a new vendor-specific AI interface.

Why this one is smaller and more cautious than our other repos

Jobber is the biggest platform in this whole series by user count (Jobber reports 250,000+ users), which is exactly why we wanted to include it. But it's also the only one where we couldn't fully verify the API schema before building, and we want to be straight about that rather than quietly paper over it.

The core issue: Jobber's API is GraphQL-based, and Jobber doesn't publish a static, field-by-field schema reference anywhere public. Their own docs say so directly: "For the most up-to-date schema, please follow our Getting Started steps and view everything in GraphiQL." To reach that live schema browser, you need a Jobber account, a separate Developer Center account, and an app registered inside it, all free and self-service, but all account-creation steps. We don't create accounts on your behalf, as a matter of policy (that's true across everything we build, not specific to Jobber), so we built this from what's genuinely public instead:

Jobber's own Developer Center overview page (public, no login), which lists the API's object types: Clients, Requests, Jobs, Quotes, Invoices, Accounts, Assessments, Expenses, Products/Services, Time Sheet Entries, Properties, Users, Visits
Jobber's official open-source app template (GetJobber/Jobber-AppTemplate-RailsAPI on GitHub), which includes a real, working clients query example
A third-party AI-tooling reference (maton-ai/api-gateway-skill on GitHub) that documents a distilled but genuine field list for Client, Job, Invoice, Quote, Property, User, and Account, plus two confirmed mutations (clientCreate, jobCreate) and the pagination/auth conventions

That's enough to build list and get tools for six object types, plus the two mutations we found concrete evidence for. It is not enough to confidently build update or delete mutations for anything; we have no verified evidence of what Jobber calls those (could be clientEdit, clientUpdate, jobClose, or something else entirely), and guessing at mutation names for a live API felt like the wrong tradeoff. So this repo doesn't have them yet.

Every list/get tool includes a fields parameter that lets you override the default field selection with a raw GraphQL selection set. This exists specifically because we can't guarantee our default field names exactly match your account's schema; if a tool errors on a field that doesn't exist, that's the escape hatch.

If you have real Jobber Developer Center access, opening GraphiQL and confirming the actual field names and mutation list would make this repo dramatically better and is genuinely useful. Contributions very welcome.

Also from BackCrew

This is one of several MCP connectors BackCrew builds, same idea, different software. We've also got QuickBooks for the accounting side, plus CRM connectors like HubSpot and GoHighLevel for lead and marketing data. Full list and what's live right now: see ROADMAP.md.

Beyond this repo: once a business gets comfortable with an AI assistant reading its data, there's often more it wants to do with it, like catching missed calls faster, processing invoices and paperwork automatically, following up on quotes without someone having to remember, reactivating customers who've gone quiet, or pulling reports without digging through the software. That's a separate, scoped conversation, not part of this free, open-source repo. Same contact as in Built by BackCrew below if it's something you want to explore.

Some words you'll see, explained

API: a locked door into Jobber's data that only software can open. This project is a key that opens that door.
GraphQL: a different style of API than most of our other repos use. Instead of one URL per action, you send a single request describing exactly which fields you want back.
MCP: the standard way an AI assistant like Claude or ChatGPT is told what it's allowed to do.
Server: a small program that sits between an AI assistant like Claude or ChatGPT and Jobber, translating requests back and forth.
OAuth: the login flow Jobber uses to issue an access token. There's no simpler "generate a key" option for Jobber, unlike some of our other repos.
Terminal: a plain-text window where you type commands.
Tool: one specific, individually named action the AI is allowed to take.

How this keeps you safe by default

Out of the box, this server can only look things up. It ships in read-only mode.
When you're ready for more, you choose a responsibility level:
- readonly-owner: same as the default. Look-ups only.
- office-ops: the two confirmed write actions this repo ships: create a client, create a job.
- admin: currently identical to office-ops. There's nothing delete/void-type confirmed yet to put here. See the scope explanation above.
A typo can't accidentally hand out more trust than you intended. An invalid profile falls back to the safest option.

What it can look up (always safe)

What it covers	Examples
Clients	Search and view client records
Jobs	View job details
Invoices	View invoice details
Quotes	View quote/estimate details
Properties	View service addresses
Users & account	View team members and basic account info

12 look-up actions in total.

⚠️ What it can change (off by default)

office-ops level: the only two write actions in this repo, both confirmed against real Jobber schema evidence:

Create a new client
Create a new job for a client

That's it for now. See why above.

How to set it up

This one has an extra wrinkle: Jobber requires an OAuth login flow instead of a simple "generate a key" button, so Step 2 below takes longer than in our other repos; budget about 15 minutes for it. Still, do these three steps in order and you won't have to jump back and forth.

You'll need a computer with Node.js installed before you start.

Step 1: Make a folder for this on your computer

Open Finder (Mac) or File Explorer (Windows), go to your Desktop or Documents, and create a new folder. Give it a name you'll recognize later, like backcrew-mcp-jobber.

That's it for now: just know where this folder is. Everything else gets put inside it.

Step 2: Get a Jobber access token

This is the one extra step Jobber requires that our other repos don't; it's entirely free and self-service, Jobber just doesn't offer a simpler path for this particular API. Do this now, before touching the terminal:

Go to Jobber's Developer Center
If you don't already have a Jobber account to test with, follow their "Create a New Jobber Account To Test With" instructions
Create a free Developer Center account and register an app (any name/description is fine, since you can change it later)
Follow Jobber's OAuth 2.0 flow to authorize your own account and get an access token
Copy that access token into a temporary note somewhere; you'll paste it in during Step 3

Step 3: Install it

With your folder made and your access token in hand, this is one continuous run; don't skip ahead or double back.

Open a terminal. On a Mac, press Cmd+Space, type "Terminal," and hit enter. On Windows, click the Start menu, type "PowerShell," and hit enter. Use PowerShell rather than Command Prompt: a couple of the commands below, like pwd, only work in PowerShell.
Type cd (with a space after it), then drag your Step 1 folder from Finder/File Explorer straight into the terminal window; it'll paste the folder's path in automatically. Press enter.
Paste this exact command and press enter; it downloads the project directly into the folder you made (the trailing . matters, it means "put it here, not in a new folder"):
```
git clone https://github.com/jayson-svg/backcrew-mcp-jobber.git .
```
Paste this and press enter; it installs the project's dependencies:
```
npm install
```
Paste this and press enter; it builds the project:
```
npm run build
```
Paste this and press enter; it prints the full folder path. Don't close this terminal window yet; you'll need this exact text in the next section.
```
pwd
```
Paste this and press enter; it creates your settings file from a template:
```
cp .env.example .env
```
Open that new .env file in a text editor. On a Mac, paste open -e .env into the terminal and press enter. On Windows, paste notepad .env and press enter.
Find the line that says JOBBER_ACCESS_TOKEN=. Paste in the token you copied in Step 2, right after the =, with no extra spaces or quotes.
Leave JOBBER_MCP_MODE=read_only and JOBBER_MCP_PROFILE=readonly-owner exactly as they are for now; that's the safe default. Save the file and close the editor.

Connecting it to Claude

This step comes last on purpose; it needs the exact folder location from Step 3, and now you have it.

Open Claude's settings file (for Claude Desktop, claude_desktop_config.json) and add:

{
  "mcpServers": {
    "jobber": {
      "command": "node",
      "args": ["PASTE_YOUR_PWD_OUTPUT_HERE/dist/index.js"],
      "env": {
        "JOBBER_ACCESS_TOKEN": "your_token_here",
        "JOBBER_MCP_MODE": "read_only",
        "JOBBER_MCP_PROFILE": "readonly-owner"
      }
    }
  }
}

Replace PASTE_YOUR_PWD_OUTPUT_HERE with the exact text the pwd command printed back in Step 3 (keep the /dist/index.js part after it). If you're on Windows, swap any backslashes in that path for forward slashes (for example C:/Users/yourname/Desktop/... instead of C:\Users\yourname\Desktop\...), since the config file needs regular slashes.

Restart Claude. Also works with other MCP-compatible AI tools, like ChatGPT.

Testing it safely

Start in read-only mode and stay there for a while.
When you turn on office-ops, test on a clearly fake client first.
Never share your access token: treat it like a password.
If a tool errors on an unrecognized field, try the fields parameter to supply your own GraphQL selection. See why above for why this exists.
If something looks wrong, switch back to JOBBER_MCP_MODE=read_only immediately.

For developers

Everything below this point assumes a coding background.

Tool reference

Run the server and call tools/list to see exact schemas.

Project layout

src/
  index.ts          Server entrypoint
  client.ts          GraphQL client (Bearer auth + X-JOBBER-GRAPHQL-VERSION header)
  toolkit.ts          Tier/profile-aware helper that wires a Zod input schema + handler into an MCP tool
  tools/
    clients.ts
    jobs.ts
    invoicesAndQuotes.ts
    propertiesAndAccount.ts

The tier/profile system

Same pattern as the rest of this series. JOBBER_MCP_MODE/JOBBER_MCP_PROFILE gate what's registered at startup; read_only always wins; invalid profile falls back to the safest tier.

Notes on the Jobber API

Endpoint: POST https://api.getjobber.com/api/graphql (single endpoint for everything, as with all GraphQL APIs)
Auth: Authorization: Bearer <access_token> plus a required X-JOBBER-GRAPHQL-VERSION header (this repo uses 2025-04-16, current as of when this was built; check Jobber's docs if requests start failing, as this may need bumping)
Pagination: Relay-style cursors (first, after args; pageInfo { hasNextPage endCursor } in the response)
IDs are EncodedId: opaque base64-ish strings, not raw UUIDs. Treat them as opaque; don't try to decode or construct them.
Rate limits: 2,500 requests per 5 minutes; query cost limit of 10,000 points per request (per Jobber's public docs)

Confidence level, to be blunt about it: the six list/get object types and their default field selections, plus the two create mutations, are grounded in real evidence (Jobber's own app template + a third-party integration reference), not guesses about what a typical GraphQL API "probably" looks like. But none of it has been tested against a live Jobber account by us, and Jobber's schema could easily have moved since the source material was written. Treat this repo as a solid starting point, not a verified-against-production reference the way the other repos in this series are.

This repo intentionally stops at honest API access. It does not include business-logic features; those live in BackCrew's managed offering, not in this public repo. See ROADMAP.md.

What's next

See ROADMAP.md for the rest of the planned series, and for what this repo needs next (real GraphiQL-verified field names).

Built by BackCrew

This project is free and open for anyone to use, copy, or build on.

It's also a sample of the kind of work BackCrew does. If you have real Jobber Developer Center access and want this expanded and verified, or you'd rather not deal with Jobber's OAuth setup yourself, that's exactly the kind of project we take on.

Want this done for you? Reach out: jayson@backcrew.co

No pressure either way; everything above works on its own, for free.

License

MIT

Available Tools

12 tools

get_accountA

Get the connected Jobber account's basic info. Maps to the GraphQL account query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`fields`	No	GraphQL selection set to fetch, overriding the default (id name).

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the burden. It mentions the tool is 'readonly-owner' and maps to a GraphQL query, implying a safe read operation. However, it does not explicitly state idempotency, side effects, or auth requirements beyond the tier tag.

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 extremely concise: two sentences and a tier tag. Every word is meaningful, no fluff. It is front-loaded with the primary purpose.

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?

For a simple get operation with one optional parameter and no output schema, the description is complete. It covers the purpose, GraphQL mapping, and permission tier. No additional context is needed for effective use.

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?

The only parameter, 'fields', is described in both the schema and the tool description. The schema coverage is 100%, so the description adds no extra meaning beyond what the schema already provides. 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?

The description clearly states the tool 'Get the connected Jobber account's basic info', specifying the verb ('Get'), resource ('account'), and scope ('basic info'). It distinguishes itself from sibling tools like get_client or list_jobs by focusing on the account entity.

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 provides clear context (read-only owner tier, GraphQL mapping), but does not explicitly state when to use this tool vs alternatives. However, since siblings target different entities, the usage is implicitly clear.

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

get_clientA

Get a single client by ID. Maps to the GraphQL client query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Jobber EncodedId for the client
`fields`	No	GraphQL selection set to fetch, overriding the default (id name emails { address } phones { number }).

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden. It adds behavioral context with '[tier: readonly-owner]', indicating read-only access and owner-level permissions, which helps agents understand safety and authorization. No further details on side effects or rate limits, but the tier information is valuable.

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 extremely concise with two short sentences, no redundant information, and front-loaded key purpose. Every word adds value.

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?

For a simple retrieval tool with two well-documented parameters and no output schema, the description covers the main purpose and behavioral tier. It could optionally mention default fields or error handling, but it is sufficiently complete.

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%, so the schema already documents both parameters. The description does not add further meaning beyond what is in the schema, such as clarifying the 'fields' parameter usage or format. Baseline score of 3 is appropriate.

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 clearly states the tool retrieves a single client by ID, with verb 'Get' and specific resource 'client'. It distinguishes from sibling tools like 'list_clients' (which retrieves multiple clients) and other 'get_*' tools. The mention of the GraphQL 'client' query adds clarity.

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?

The description implies use for single client retrieval by ID but does not explicitly state when or when not to use it. No mention of alternatives like 'list_clients' or conditions for skipping this tool.

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

get_invoiceB

Get a single invoice by ID. Maps to the GraphQL invoice query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Jobber EncodedId for the invoice
`fields`	No	GraphQL selection set to fetch, overriding the default (id invoiceNumber total invoiceStatus).

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description must carry full behavioral disclosure. It mentions a tier 'readonly-owner', hinting at read-only access and ownership requirements, but lacks details on side effects, rate limits, or response 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 extremely concise with one sentence and two tags, no wasted words. It front-loads the core action and includes relevant context (GraphQL mapping and permission tier). Every element earns its 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?

Given no output schema, the description does not explain what fields are returned or provide any completeness about the response. It is minimally adequate for a simple retrieval tool but lacks depth.

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 coverage is 100% with descriptions for both parameters ('id' and 'fields') already present. The tool description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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 clearly states the tool retrieves a single invoice by ID. It uses a specific verb 'Get' and resource 'single invoice', distinguishing it from siblings like list_invoices which lists multiple invoices.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as list_invoices or other getters. It only states what it does without exclusions or context.

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

get_jobA

Get a single job by ID. Maps to the GraphQL job query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Jobber EncodedId for the job
`fields`	No	GraphQL selection set to fetch, overriding the default (id title jobNumber jobStatus client { id name }).

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description adds the 'readonly-owner' tier hint, disclosing the operation's read-only nature and required permissions. It also notes the underlying GraphQL query, providing some behavioral context.

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 extremely concise, using only two sentences plus a tag. It is front-loaded with the core purpose and contains no unnecessary words.

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?

The description lacks details about the return structure or error cases, and there is no output schema. However, it does mention the default fields and that the 'fields' parameter can override them, offering some completeness.

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 coverage is 100%, so the baseline is 3. The description does not add extra meaning to the parameters beyond what the schema already provides, though it does link the tool to a GraphQL query.

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 clearly states the tool retrieves a single job by ID, using a specific verb and resource. It is distinct from sibling tool 'list_jobs' which retrieves multiple jobs.

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?

The description implies usage when you have a specific job ID, but it does not explicitly compare with alternatives like 'list_jobs' or specify when not to use this tool.

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

get_propertyA

Get a single property by ID. Maps to the GraphQL property query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Jobber EncodedId for the property
`fields`	No	GraphQL selection set to fetch, overriding the default (id address { street city } client { id name }).

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries the full burden but only provides a tier tag ('readonly-owner') without explaining its meaning. It does not disclose side effects, authentication requirements, or response behavior beyond being a query.

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 extremely concise with two sentences and a tag, containing no waste. It efficiently communicates the core purpose.

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?

For a simple read tool with full schema coverage, the description adequately states intent but lacks usage guidance and deeper behavioral context. It is minimally complete but could improve with more detail.

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 coverage is 100%, so the schema describes both parameters. The description adds no new semantics beyond the schema, though the GraphQL mapping provides marginal context for the 'fields' parameter.

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 clearly states the verb 'Get' and resource 'single property by ID', distinguishing it from sibling tools like list_properties that fetch multiple properties. It also provides context by mapping to a GraphQL query.

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?

The description implies usage when you have a property ID, but does not explicitly state when to use this tool over siblings or when not to use it. No alternative or exclusion criteria are given.

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

get_quoteA

Get a single quote by ID. Maps to the GraphQL quote query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Jobber EncodedId for the quote
`fields`	No	GraphQL selection set to fetch, overriding the default (id quoteNumber title quoteStatus).

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are present, so the description carries the burden. It discloses the tool is readonly (via tier tag) and maps to a GraphQL query, which implies safety and structure. However, it does not describe behavior on invalid IDs, error handling, or any side effects. It provides some context but not comprehensive transparency.

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 extremely concise: one sentence plus a tag. Every element serves a purpose: what it does ('Get a single quote by ID'), technical backing ('Maps to the GraphQL `quote` query'), and permissions context ('[tier: readonly-owner]'). No redundant words.

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?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, technical detail, and permission model. Missing are behaviors on missing IDs or pagination, but for a single-resource retrieval tool, these are minor gaps. The sibling tools help contextualize its role.

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 coverage is 100%, with both parameters described. The description adds minimal value beyond the schema, only mentioning the GraphQL query mapping which indirectly informs the 'fields' parameter. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding.

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 clearly states it gets a single quote by ID, using a specific verb and resource. It distinguishes itself from the sibling 'list_quotes' tool by focusing on a single entity retrieval, and the mention of the GraphQL `quote` query adds specificity.

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?

The description implies usage when you have a specific quote ID, but it does not explicitly state when to use this tool versus alternatives like 'list_quotes'. No exclusions or prerequisites are mentioned. The context from sibling tools provides implicit guidance, but the description itself lacks direct usage instructions.

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

list_clientsA

List clients (customers), Relay-paginated. Maps to the GraphQL clients query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`after`	No	Pagination cursor from a previous call's pageInfo.endCursor
`first`	No	Default 20
`fields`	No	GraphQL selection set to fetch, overriding the default (id name emails { address } phones { number }). Use this if the default fields don't match your account's schema — Jobber's exact schema isn't publicly documented, so this is a safety valve.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses pagination behavior ('Relay-paginated') and a readonly tier hint, but lacks details on idempotency, rate limits, or data consistency. It adds some value but leaves gaps.

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 a single sentence with a tag, using no unnecessary words. Every element earns its place, providing clear and efficient information.

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?

For a simple list tool with three parameters, the description is mostly complete. It covers pagination and the underlying query. However, it misses details on output structure (e.g., Relay connection format) and ordering. Still adequate given no output schema.

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 coverage is 100%, so baseline is 3. The description adds the GraphQL query mapping and a safety valve note for the 'fields' parameter, but these are partially redundant with the schema description. No significant extra meaning beyond 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 explicitly states 'List clients (customers)' with a specific verb and resource. It differentiates from sibling 'get_client' by indicating a list operation. The mention of Relay pagination and GraphQL query mapping adds clarity.

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?

The description does not explicitly state when to use this tool versus alternatives like 'get_client' or other list tools. Usage is implied from the name and pagination mention, but no exclusions or context cues are provided.

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

list_invoicesA

List invoices, Relay-paginated. Maps to the GraphQL invoices query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`after`	No
`first`	No	Default 20
`fields`	No	GraphQL selection set to fetch, overriding the default (id invoiceNumber total invoiceStatus).

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions Relay-pagination and readonly-owner, but omits important details like whether it is read-only, rate limits, or what the cursor type is. The description is insufficient for this dimension.

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 extremely concise: one sentence plus a bracketed tag. It is front-loaded with the core purpose, and every part adds value. No waste.

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?

Given the tool has 3 params and no output schema, the description is somewhat incomplete. It mentions pagination and tier, but does not explain cursor usage, ordering, or what fields default includes. The agent can partially infer from sibling tools, but gaps remain.

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 coverage is 67% (2 of 3 params have descriptions). The description adds no parameter-specific information beyond what the schema provides. The 'Relay-paginated' term loosely relates to 'after' and 'first', but does not add syntax or format details, so baseline 3 is appropriate.

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 clearly states 'List invoices' with specific verb and resource. It adds context: Relay-paginated, maps to GraphQL query, and readonly-owner tier, which distinguishes it from sibling tools like list_clients or get_invoice.

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?

The description does not explicitly state when to use this tool versus alternatives like get_invoice. The 'Relay-paginated' hint and readonly-owner tier imply some context, but lack explicit when-to-use or when-not-to-use guidance.

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

list_jobsB

List jobs, Relay-paginated. Maps to the GraphQL jobs query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`after`	No
`first`	No	Default 20
`fields`	No	GraphQL selection set to fetch, overriding the default (id title jobNumber jobStatus client { id name }). Jobber's exact schema isn't publicly documented — use this if the default doesn't match your account.

TDQS

B3.1/5.0

Behavior2/5

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

Without annotations, the description carries the full burden. It discloses Relay pagination and a [tier: readonly-owner] hint, but lacks details on default behavior, ordering, response structure, or side effects. The minimal transparency is insufficient for a tool with no output schema.

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?

Three concise pieces of information, each earning its place: purpose, pagination style, and underlying query. No wasted words and front-loaded with the main action.

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

Completeness2/5

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

For a list tool with 3 parameters, no output schema, and no annotations, the description is too brief. It lacks details on what is returned by default, how pagination works concretely (e.g., cursor format), and error handling. The [tier: readonly-owner] hint is vague.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain any parameters beyond what the schema provides. Schema coverage is 67% (two of three parameters have descriptions), but the description adds no extra meaning for 'after' or 'first' in the context of Relay pagination. The pagination mention is implicit and does not directly link to parameters.

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 clearly states 'List jobs' with a specific verb and resource, and adds that it is Relay-paginated and maps to a GraphQL query. This sufficiently differentiates it from sibling tools like get_job (single job) and list_clients (different resource).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it provide prerequisites or filtering options. The description only implies a general listing use case.

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

list_propertiesA

List service properties (addresses), Relay-paginated. Maps to the GraphQL properties query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`after`	No
`first`	No	Default 20
`fields`	No	GraphQL selection set to fetch, overriding the default (id address { street city } client { id name }).

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description adds value by including a '[tier: readonly-owner]' tag indicating read-only behavior and access level. It also discloses the Relay-based pagination style. However, it does not mention authentication requirements or potential side effects, though the readonly hint mitigates this.

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?

Two sentences, each adding distinct value: first states purpose and pagination, second maps to GraphQL and adds a security tier. No redundant information.

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?

Given no output schema and moderate complexity (3 params), the description covers purpose, pagination style, and a security tier. It lacks details on the return format or error conditions, but the list operation's output is implicitly properties. Mostly complete for a paginated list tool.

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?

Schema coverage is 67%; the description compensates for the undocumented 'after' parameter by implying it's a cursor from Relay pagination. It also adds context to 'fields' as a GraphQL selection set. The description adds meaning beyond the schema, especially for the cursor parameter.

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 clearly states the verb 'list' and resource 'service properties (addresses)', includes pagination method 'Relay-paginated', and implicitly distinguishes from sibling tools like 'get_property' (single resource) by specifying it's a list operation.

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?

The description mentions it's a paginated list mapping to a GraphQL query, but lacks explicit guidance on when to use this tool versus alternatives like 'get_property' for single properties or 'list_clients' for different resources. Usage context is implied but not directly stated.

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

list_quotesA

List quotes/estimates, Relay-paginated. Maps to the GraphQL quotes query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`after`	No
`first`	No	Default 20
`fields`	No	GraphQL selection set to fetch, overriding the default (id quoteNumber title quoteStatus).

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description fully discloses behavior. States it's read-only (owner), Relay-paginated, and maps to specific GraphQL query. Lacks details like default ordering or empty result behavior, but sufficient for a list operation.

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?

Two compact sentences, each adding value: action and pagination, then mapping and tier. No fluff, front-loaded with core purpose.

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?

No output schema, but description covers pagination and read-only nature. Could mention default fields returned, but overall complete for a list tool with optional params.

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?

Schema has 67% coverage; description adds context that pagination is Relay-based (relating to after and first). Fields param is described in schema. Description effectively complements but doesn't add extensive new info.

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?

Clearly states 'List quotes/estimates' with specific verb and resource. Mentions Relay-pagination and maps to GraphQL query, distinguishing from get_quote (single item retrieval).

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?

Implies usage for paginated listing via Relay, and tier readonly-owner suggests read-only context. No explicit when-to-use or alternatives like get_quote mentioned.

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

list_usersA

List users (team members) on the account, Relay-paginated. Maps to the GraphQL users query. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`after`	No
`first`	No	Default 20
`fields`	No	GraphQL selection set to fetch, overriding the default (id name email).

TDQS

A4/5.0

Behavior4/5

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

Description adds meaningful behavioral context: Relay pagination, readonly tier, GraphQL mapping. Lacks details on error handling or auth specifics but sufficient for a simple read operation.

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?

Two concise sentences conveying purpose, pagination, mapping, and permissions. No wasted words.

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?

Covers key aspects: resource, pagination, readonly. No output schema needed? Would benefit from mention of return format or default field set, but adequate for a simple list tool.

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?

Description does not explain parameters beyond hinting pagination via 'Relay-paginated'. Schema covers two of three parameters with descriptions; no added value from description. Baseline 3.

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 clearly states the action (list) and resource (users/team members), and distinguishes from siblings like list_clients. It also provides implementation details (Relay-paginated, GraphQL mapping).

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?

No explicit when-to-use or when-not-to-use guidance. Purpose is clear from resource name, but alternatives or exclusions are not mentioned. Minimal guidance.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct resource (clients, account, jobs, invoices, quotes, properties, users) with either list or get operations. There is no ambiguity between tools.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., list_clients, get_job, get_invoice). No deviations or mixed conventions.

Tool Count5/5

With 12 tools, the set is well-scoped for a read-only server focused on core entities of a field service management platform. Not too many, not too few.

Completeness4/5

The tools cover read operations for all major entities (clients, jobs, invoices, quotes, properties, users). Missing write operations and potentially entities like visits, but the read-only scope is clearly stated and consistently implemented.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-server
com.syncrosecure
Connect any AI assistant to Syncro: manage tickets, invoices, customers, assets, and more.
Customer Support Payments & Billing CRM
1
GitHub
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1232,678
golemry
com.golemry
Create and manage scheduled, guarded AI agent jobs with built-in quality control and 900+ connectors
Agent Orchestration Autonomous Agents App Automation
3
mcp
com.keboola
Connect your AI assistants to Keboola and expose your data, transformations, SQL queries, ...
Data Platforms Databases Developer Tools
286

Related MCP Servers

Jobber MCP Server
CRM Project Management
friendlygeorge
A
license
A
quality
F
maintenance
Enables AI assistants to access and manage Jobber field-service data including clients, jobs, invoices, and quotes through natural language interactions.
Updated 3 months ago (2026-06-11 17:10 UTC)
6
52
MIT
Jobber MCP Connector
CRM Project Management
Medina-Digital-A-i
F
license
Not graded
quality
F
maintenance
Connects Claude to Jobber to manage clients, jobs, invoices, quotes, and scheduling through natural language.
Updated 5 months ago (2026-03-27 21:59 UTC)
BackCrew Housecall Pro MCP
jayson-svg
A
license
B
quality
B
maintenance
Connects AI assistants to Housecall Pro to look up and manage customers, jobs, invoices, and more through natural language. Operates in read-only mode by default with optional write capabilities.
Updated a month ago (2026-07-22 15:31 UTC)
30
1
MIT
jobkeepr-mcp
ERP Systems CRM Finance
dandyer
A
license
Not graded
quality
B
maintenance
Enables AI assistants to read and manage a Jobkeepr field service business including jobs, customers, scheduling, estimates, invoices, and payments via MCP.
Updated 24 days ago (2026-08-11 04:52 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jayson-svg/backcrew-mcp-jobber'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

BackCrew Jobber MCP Server

Contents

What this actually does

Why use an independent MCP server instead of the platform's own AI?

Why this one is smaller and more cautious than our other repos

Also from BackCrew

Some words you'll see, explained

How this keeps you safe by default

What it can look up (always safe)

⚠️ What it can change (off by default)

How to set it up

Step 1: Make a folder for this on your computer

Step 2: Get a Jobber access token

Step 3: Install it

Connecting it to Claude

Testing it safely

For developers

Tool reference

Project layout

The tier/profile system

Notes on the Jobber API

What's next

Built by BackCrew

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API