How to Connect JobTread to Claude AI: A Contractor's Guide

Most contractors using AI right now are doing it in a browser tab. You copy a spec section into Claude, ask it something, copy the answer back out. It works, and it is a fraction of what the tool can do.

The step most people have not taken is connecting Claude directly to the system where their jobs actually live. When you do that, Claude stops guessing from pasted text and starts reading your real budgets, cost items, documents, tasks, and daily logs. You can ask a question about a job from eighteen months ago and get an answer in four seconds.

JobTread made this considerably easier than it used to be. They built and published their own MCP server, which they call the AI Connector, so this is now a setup task rather than a development project.

This guide covers the exact setup, the one decision in it that actually matters, what the connector can genuinely do once it is running, the API underneath it for anything the connector does not cover, and the risks that JobTread's own documentation is refreshingly honest about.

What the AI Connector actually is

MCP stands for Model Context Protocol. It is an open standard for letting an AI assistant talk to an external system: the AI asks for something, the server decides whether it is allowed and returns the result. It is deliberately not AI-vendor-specific.

That last detail is the strategically interesting part of what JobTread did. They did not build AI features into JobTread. They exposed their data through an MCP server so you can point whatever AI tool you prefer at it. Claude today, something that does not exist yet in two years, same connector.

Underneath the connector sits JobTread's public API, called the Pave API. Everything the connector does, it does by making Pave API calls on your behalf. You do not need to know that to use it, but it matters later when you want to do something the connector does not do on its own, so there is a section on it below.

Two facts about the connector are worth fixing in your head before you set it up, both straight from JobTread's documentation:

It acts as you. The connector operates under your JobTread account permissions. Any action it takes is performed as you, with your access. There is no separate sandbox.

There is no undo. JobTread states plainly that the connector has no built-in undo function for changes it makes. This is not a criticism of the product, it is how an API works. It is the reason the permission tier you choose is the most consequential decision in this entire process.

What you need before you start

Requirement	Detail
JobTread account	Active, with login credentials. You need permission to create grants.
Claude account	Free works with limited functionality. Paid gives full functionality.
About five minutes	The setup itself is genuinely quick.
A decision made in advance	Which permission tier, and what the AI should never touch.

That last row is the one people skip, and it is the only one that is hard.

Part one: connecting JobTread to Claude

The flow runs through Claude's custom connector feature, then hands off to JobTread to authorize.

1. Open Claude's connector settings. Click the Customize icon in Claude's main navigation, or go directly to claude.ai/customize/connectors. Select Connectors from the sub-menu.

2. Add a custom connector. Click the plus icon and choose Add Custom Connector.

3. Name it. Use something that identifies the specific JobTread organization, not just "JobTread." If you ever connect a second organization you will be glad you did. Something like JobTread - Big Ranch Construction works.

4. Enter the MCP server URL. The server is:

https://api.jobtread.com/mcp

Add a question mark and a distinguishing suffix after it, like this:

https://api.jobtread.com/mcp?big-ranch-construction

The suffix does nothing functionally. It exists because Claude requires a unique URL per connector, so if you want to connect two JobTread organizations to the same Claude account you need two different-looking URLs. Set it up this way from the start even with one organization, because retrofitting it later means redoing the connection.

5. Connect and authorize. Click your new connector in the list, then select Connect. Claude redirects you to a JobTread authentication page, and you may be prompted to log in to JobTread first.

6. Choose your permission tier. This is the decision that matters. It gets its own section below, immediately after this one. Do not skim it.

7. Enter a Grant Name. This name appears in the JobTread history log against every action taken through the connection. Choose something unmistakable like Claude AI Connector, because this is what lets you look at a change in JobTread later and know whether a person or the AI made it. A grant named after yourself makes AI actions indistinguishable from your own, which defeats the purpose of having a log.

That is the whole setup. Claude now has a JobTread tool available.

The permission tier is the decision that matters

JobTread scopes each grant to one of three tiers:

Tier	What it allows	Who it is for
Read	View data only. Cannot change anything.	Almost everyone, at least to start
Write	Read, plus create and update records	Specific workflows you have already run manually
Delete	Full read, write, and delete	Rarely justified for an AI connection

Start on Read. I want to be direct about why, because most articles about this will not be.

When you introspect the JobTread API schema, the read operations are only part of what is there. Sitting alongside them are createJob, updateJob, deleteJob, createDocument, deleteDocument, createCostItem, deleteCostItem, deleteCostGroup, deletePayment, and many more. That is a complete, capable API, which is exactly what you want for building integrations and exactly what deserves care when a language model is holding the other end.

Combine that with the two facts from earlier. The AI acts as you, with your permissions. There is no undo. A model that can delete a cost group is a model that can delete a cost group, and the way it happens is not dramatic: you phrase a request loosely, it interprets the scope more broadly than you meant, and now you are rebuilding something.

JobTread's own guidance draws the same line, splitting usage into safe and aggressive:

Safe use	Aggressive use
Reading data	Modifying records
Drafting content for review	Sending documents
Summarizing job status	Bulk edits without review

Run on Read for a month. You will find almost everything in the next section works fine without write access, and you will have a far better sense of which specific workflow would justify more. When you do upgrade, upgrade for that workflow, not as a general convenience.

One more practical note: JobTread grant keys expire after three months of inactivity. If your connector silently stops working after a quiet quarter, that is usually why.

Connecting from Claude Code or other tools

Because it is a standard MCP server over HTTP, the connector is not limited to the Claude web app. In Claude Code, you add it from the terminal:

claude mcp add --transport http jobtread https://api.jobtread.com/mcp

Then run /mcp inside Claude Code to trigger the authorization flow. The same grant and permission tier rules apply, and the same caution applies more so, since an agentic coding tool is by design more willing to take multi-step action than a chat window.

ChatGPT and other MCP-capable tools connect through their own equivalent of the custom connector flow. The server is the same.

Verifying it actually works

Do not skip this, and do not test it on a job you are unfamiliar with.

Pick a completed job you remember in detail and ask Claude questions you already know the answers to. What was the final cost. Which cost group ran over. When did it close. How many change orders were there.

You are not testing whether the connection works, because you will know that in ten seconds. You are calibrating. You are finding out where it is confidently wrong, which is the only honest way to decide how much weight to put on its answers later.

A good first request is simply: "List the last five jobs and their projected and actual cost." If numbers come back, you are connected and your budget data is populated. If the jobs come back with empty cost fields, that tells you something important, which is the subject of a later section.

Part two: what it can actually do

This is worth being specific about, because "AI for your construction data" means nothing until you see the questions.

Cross-job questions your reports were not built for

JobTread's reports handle the questions you ask every week. They are not built for the question you think of on a Tuesday. With the connector, those become conversational:

• Which jobs have an actual cost above their projected cost, and by how much?
• Across every job we closed this year, which cost groups ran over most often?
• Which open jobs have had no daily log entry in the last two weeks?
• What did we charge for demo work on the last six bathroom remodels?
• Which customers have more than one job with us, and what is the total value?
• Which jobs have documents that were sent but never paid?

That fourth one is where it earns its keep fastest. "What did we charge last time we did this" normally means digging through old jobs for twenty minutes. Now it is a sentence, and the answer comes with the jobs it came from so you can check it.

Whole-job briefings

A JobTread job carries a lot: its budget, cost items, documents, tasks, daily logs, time entries, files, comments, and custom field values. Claude can read across all of it in one pass and compress it.

This is genuinely useful before a client meeting. "Summarize everything that has happened on this job in the last month and flag anything that looks like it is heading toward a change order" gives you a briefing off real project activity instead of your memory of it.

Cost catalog auditing

This one surprises people, and it is one of the best uses of the tool.

Point Claude at your cost catalog and ask it to find the problems. It will find them: duplicate items under slightly different names, inconsistent units on similar work, cost groups that have drifted out of sequence, items nobody has used in two years, naming conventions that changed halfway through 2024 and were never reconciled.

Cost catalog quality is the foundation everything else in JobTread rests on, and auditing it by hand is miserable work that never gets prioritized. An AI reading the whole catalog at once is well suited to it. If yours needs rebuilding rather than cleaning, our JobTread cost catalog template is a better starting point than patching in place.

Drafting from real data

Client updates, owner reports, change order narratives, and job summaries all follow the same shape: gather what happened, then write it up. The gathering is now instant and the first draft arrives with it.

The rule that keeps this safe is simple. Claude drafts, a person reviews, nothing reaches a client unread. That is not a limitation of the technology, it is ordinary professional practice, and the first time you skip it you will send a client something confidently wrong.

Reporting preparation

WIP schedules, owner reports, and weekly job status summaries are mostly assembly work: pull the numbers, arrange them, spot what changed. That is well within what the connector handles, and it pairs naturally with broader construction automation and analytics once you know which reports you actually want.

Accounting and field context

Jobs in JobTread carry references to their QuickBooks records (qboId, qboClassId) and CompanyCam records (companycamId). The data model knows those links exist, which is what makes questions spanning systems tractable rather than theoretical.

Part three: the Pave API, for everything else

The connector covers most of what a contractor needs. When you want something it does not do, such as a scheduled report, a custom dashboard, or a two-way sync with another system, you go to the API directly. This section is for whoever builds that.

The endpoint. Everything is a POST to a single URL:

POST https://api.jobtread.com/pave
Content-Type: application/json

Authentication. You create a grant from JobTread's grant management page. The key is displayed exactly once, so capture it immediately. It goes in the request body under query.$.grantKey:

curl https://api.jobtread.com/pave \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {
      "
quot;: { "grantKey": "YOUR_GRANT_KEY" },
      "currentGrant": { "organization": { "id": {}, "name": {} } }
    }
  }'

That call is also the fastest way to get your organization ID, which most other queries need.

The query language. Pave is a JSON graph API. It behaves like GraphQL but you write queries as JSON objects rather than in a separate query language. Three rules cover most of it:

1. Top-level keys are root field names.
2. Select a scalar by giving it an empty object: {}.
3. Arguments go under a special $ key.

So a query for jobs with their cost figures looks like this:

{
  "query": {
    "
quot;: { "grantKey": "YOUR_GRANT_KEY" },
    "organization": {
      "
quot;: { "id": "YOUR_ORG_ID" },
      "jobs": {
        "
quot;: { "size": 25 },
        "count": {},
        "nodes": {
          "name": {},
          "projectedCost": {},
          "actualCost": {},
          "projectedPrice": {},
          "closedOn": {}
        }
      }
    }
  }
}

Introspecting the schema. You do not have to guess at field names. The API documents itself:

{ "schema": { "
quot;: { "path": "root" } } }

That returns every root field with a description. To search rather than read the whole thing:

{ "schema": { "
quot;: { "path": "root", "search": "invoice" } } }

And to expand one field, including its arguments and return type:

{ "schema": { "
quot;: { "expand": true, "path": "root.job" } } }

Paths are built by appending a segment per layer: .fieldName for an object key, .$ for an input, and ._on_variant for a oneOf variant. So the input to createJob under a variant called bar would be root.createJob.$._on_bar.

Aliases and aggregates. The _ key aliases a field to a schema type, which lets you query the same connection twice under different names or compute sums:

{
  "job": {
    "
quot;: { "id": "YOUR_JOB_ID" },
    "documents": {
      "count": {},
      "priceSum": { "_": "sum", "
quot;: "price" }
    }
  }
}

What a job carries. Useful to know when planning queries. A job exposes actualCost, projectedCost, projectedPrice, projectedPriceWithTax, costItems, costGroups, documents, tasks, dailyLogs, timeEntries, files, comments, customFieldValues, areas, plans, location, number, closedOn, and the QuickBooks and CompanyCam identifiers.

Other options in $. Alongside grantKey you can pass notify (set false to suppress notifications your calls would otherwise trigger, which matters for bulk operations), timeZone (an IANA zone for time-aware data), and viaUserId to scope results to a particular user.

The full reference lives at app.jobtread.com/docs.

Where it breaks

I ran a query against a live JobTread account while writing this: pull projected cost and actual cost for a handful of jobs. The API returned the jobs and returned empty values for every cost field.

Nothing was broken. Those jobs simply did not have budgets populated. They were leads and early-stage records, which is entirely normal in a working account with around a hundred jobs in it.

But sit with what that means with an AI in the loop. Ask "what is our average cost overrun" against an account like that, and the honest answer depends completely on which jobs happened to have data. The model may tell you it found nothing. It may also compute an average across the six jobs that did have numbers and present it with exactly the same confidence it would give a complete answer.

This is the most important thing to understand about AI on your project data. The tool does not know what your account is missing. It reports what it finds, and what it finds is a direct function of how disciplined your team has been about filling things in.

Which leads somewhere uncomfortable. If your JobTread account is not well structured and consistently maintained, connecting an AI to it does not produce insight. It produces faster, more confident wrong answers, delivered in fluent prose that reads like analysis. Get the implementation right first. The AI is a layer on top, not a repair.

A useful habit that mitigates this: ask for the working, not just the answer. "Which jobs are over budget, and list the jobs you checked and any where the data was missing" turns a confident summary into something you can audit in ten seconds.

How to leverage it by role

The value looks different depending on who is asking.

Role	Highest-value use	What to avoid
Owner	Cross-job profitability questions, WIP prep, "which jobs need my attention"	Treating any number as final without checking the source
Estimator	"What did we charge last time," scope sheets from specs, catalog auditing	Letting it price anything
Project manager	Job briefings before client meetings, draft updates, finding stale jobs	Sending drafts unread
Bookkeeper	Finding jobs where costs and documents disagree, payment follow-up lists	Reconciliation, which stays a human job
Admin or VA	Data quality audits, incomplete record sweeps, reporting prep	Bulk changes without a review step

The pattern across all of them: questions and first drafts, not decisions and final answers.

A realistic starting sequence

1. Audit your JobTread data first. Honestly. If budgets are half populated and the cost catalog has grown organically for three years, start there rather than here.
2. Connect on the Read tier. No write access for the first month.
3. Name the grant so it is identifiable in the history log. Claude AI Connector, not your own name.
4. Test against jobs you know cold. Find out where it is wrong before you rely on it.
5. Pick three recurring questions your team asks that currently take too long, and make those the use case. Not "explore what AI can do," which produces a week of demos and no change in how anyone works.
6. Write down what it may never touch. Client confidential documents, employee records, anything under NDA. Decide this before someone asks it in the moment.
7. Only then consider Write, scoped to a specific workflow you have already run manually enough times to trust.

What this does not replace

It does not replace your JobTread reports and dashboards. Reports are better for the numbers you look at weekly, because they are consistent, repeatable, and nobody has to phrase them correctly to get the same answer twice. The connector is for the questions between the reports.

It does not replace an estimator. It gets an estimator to the point where they can think, faster.

It does not replace keeping your system current. If anything it raises the stakes, because stale data now surfaces as confident prose instead of an obviously empty report. That is the case for someone owning the job of keeping it accurate.

The short version

Connecting JobTread to Claude is a five-minute setup through an official connector JobTread built and maintains. The Read tier delivers most of the value and carries little risk. Write and Delete are powerful, have no undo, and act under your own account permissions, so they deserve considerably more thought than the setup screen implies.

Whether any of it works comes down to something other than the AI: whether your JobTread account is structured well enough to be worth asking questions about.

If you want this set up properly, including the part where someone decides what it should and should not be allowed to see, that is what we do.