Building AI Agents for Construction with MCP Tools and Procore

Many construction AI demos stop at a chat box that summarizes a PDF. That is useful, but it is not where the work happens. The work happens inside Procore, the schedule, the ERP and the reporting stack, and an assistant that cannot reach those systems can only guess at the answers people actually need: what is this project's budget doing, which commitments are open, what changed since last month.

In this walkthrough of Construct.Chat, the construction agent platform built by our founder Charley Forey, we show a different pattern. You create an agent, give it a specific set of MCP tools that call the Procore API, ask questions in plain language, and then inspect every tool call the agent made. This article explains how that works, why it was built that way, and what it means if you are thinking about putting agents on your own project data.

The problem: agents without tools are just guessing

A large language model on its own knows how construction works in general. It does not know your projects, your budget line items or your change events. To answer "how is the Sparkling Skyrise project tracking against budget?" it needs to:

1. Find the project in your Procore company.
2. Pull its details.
3. Pull the financial records that matter: budgets, estimates and related cost data.
4. Reason over the results and explain them.

Each of those steps is an API call. The question is how you let a model make those calls safely, predictably and in a way you can audit afterwards. That is the job the Model Context Protocol was designed for. MCP gives a model a defined list of tools, each with a name, a description and an input schema, and a server that executes them. The model decides which tool to call; the server does the actual work against the system. You can read the protocol itself at modelcontextprotocol.io.

How the agent is put together

In the demo, the agent is called the Procore Project Financials Insights Agent. Its purpose is narrow on purpose: give financial insight into construction projects by querying Procore through the API and MCP tools, then return detailed responses to whatever the user asks.

Building it comes down to a handful of choices.

Connecting the Procore MCP

The Procore MCP connection takes five inputs: the Procore client ID, client secret, company ID, the environment (sandbox or production), and a Construct.Chat API key. The first four authenticate against Procore. The last one ties every tool call back to a telemetry dashboard, which we cover below.

Once that is provisioned, you pick which tools the agent may use. In the demo, only the list and show tools were selected, which means the agent can read but not create, update or delete. The server also offers tools that create, update and delete records in Procore, but a financial insights agent has no reason to change anything. Choosing the tool list is the first and most effective access control you have.

That point is worth stating directly: the tool list is the agent's permission boundary. If a tool is not selected, the agent cannot call it, no matter how the user phrases the request. This is the least privilege principle applied at the tool level, and it is far easier to reason about than trying to steer a model with instructions alone.

Walking through a real conversation

The demo conversation shows the agent working step by step against live Procore data.

1. "What projects am I working on?" The agent called the list projects tool and returned the projects available to the account.
2. "I want to know more about this project" (the Sparkling Skyrise project, with its ID). The agent called the get project details tool and wrote a detailed summary of the project.
3. "Tell me more about the project financials." This time the agent chained several MCP tools, making multiple API requests, and returned a breakdown covering budgets, estimates and recommendations.
4. Follow-up. From there you can keep asking for deeper detail or have the agent run calculations on what it pulled.

Two things stand out. First, every response is grounded in an actual tool call you can see in the chat, not in the model's memory. Second, the agent decides how many calls to make. A simple question took one call; the financials question took many. That is the practical value of an agent over a fixed report: it can follow the question wherever it goes, within the tools you allowed.

The part most demos skip: tool-call telemetry

The Construct.Chat API key does something important. Every time an MCP tool runs, the request is recorded in the Construct.Chat API dashboard. A new key is created for each customer, so every call can be attributed to the customer whose agent made it.

For each recent tool call, the dashboard shows:

• Which tool ran (for example list projects)
• The request URL that was called
• Query parameters, headers and arguments
• The result and the response returned to the chat interface
• Whether the call succeeded or failed

In the demo, one call had failed, and the dashboard lets you open it and see why. That matters because APIs change. A vendor may move an endpoint, rename a parameter or add a required field. Without per-call visibility, an agent quietly gets worse and nobody knows which tool broke. With it, you can see the failure, update the MCP tool, and confirm the fix.

The dashboard also includes analytics: charts of which tools are called and how often. That tells you where to spend engineering time. A tool that is called constantly and fails occasionally deserves attention before a tool nobody uses.

There is a longer-term reason to capture this data too. A record of real questions, the tools chosen to answer them and the results returned is exactly the kind of data you would want for fine-tuning a construction-specific model later. The demo describes that as a future direction, not something already shipped, and we would treat it the same way: capture the evidence now because it is valuable for debugging today and for training decisions later.

This is the evidence on every output principle in practice. If an agent tells a CFO the budget is tracking over, someone should be able to see exactly which API calls produced that answer.

Inside the Procore MCP server

The demo also opens the codebase of the Procore MCP server, written in TypeScript. At the time of recording it held about 735 tools, starting with Procore's Construction Financials module and most of the Core module, with Project Management and other modules planned next. A JavaScript verification script confirmed the tool count and ran a live list projects test to check that authentication and the API path worked end to end.

The structure is worth copying if you are building your own MCP server against a large API:

Why this structure works

Organize by the vendor's own modules. Procore groups its API into modules, so the server does too. When Procore changes something in Construction Financials, you know exactly which folder to open.

Separate definitions from handlers. Each tool has a definition (name, description, schema the model sees) and a handler (the code that calls the API). Keeping them apart makes it easy to improve a description so the model picks the right tool, without touching the code that runs it.

Register tools centrally. A registry means the server knows its full inventory. That is what makes it possible to count tools, test them and expose a filtered subset to a given agent.

Make telemetry a service, not an afterthought. Because recording tool calls lives in its own service, every tool gets it for free.

When an API surface gets this large, the next problem is routing: a model handed hundreds of tools at once picks less reliably and spends much of its context reading tool descriptions. We cover how to handle that in routing 2,755 Procore API tools and the Tool Runtime MCP gateway.

What this means for your company

If you run a contractor and are weighing AI agents, this demo suggests a few practical questions to ask of any agent, ours or anyone else's.

• What tools can it call, exactly? You should be able to see and limit the list.
• Is it read-only or can it write? Start read-only. Add write tools one at a time, with a reason and an owner.
• Whose credentials does it use? Sandbox before production, and scoped credentials before broad ones.
• Can you see every call it made? If not, you cannot debug it, and you cannot defend its answers.
• What happens when the vendor API changes? There should be a way to detect failing tools quickly.

These are the same questions we work through in our guide to governing AI agents in construction.

Lessons from building it

Narrow agents beat general ones. A "project financials insights" agent with read-only financial tools is easier to trust than a do-everything assistant.

Tool selection is security. The cheapest, most reliable control is not giving the agent a tool it does not need.

Log everything the agent does. Request, parameters, response and status for every call. It is the difference between "the AI said so" and an answer you can check.

Test against the real API early. A simple automated check, like listing projects with real credentials, catches authentication and configuration problems before users do.

Build for the next system. The demo started with Procore, with other construction systems planned, so an agent can work across the tools in your stack. A consistent server structure makes each new system faster to add.

Where to go next

• Watch the full walkthrough on the Construct.Chat agents demo page.
• New to the protocol? Start with what MCP means for construction.
• See how a large tool catalog is handled in routing 2,755 Procore API tools.
• Thinking about an agent on your own Procore or ERP data? Tell us what you want to build and we will help you scope the tools, access and audit trail.