What Is MCP? A Practical Guide for Construction Teams

The Model Context Protocol (MCP) is an open standard that lets an AI application connect to outside systems through a common interface. A system like Procore, Primavera P6, or your ERP is wrapped in an "MCP server" that exposes a defined set of tools, and any MCP-compatible client (Claude Desktop, Cursor, or a custom agent) can discover and call them. For construction teams, MCP is the layer that turns "the AI can talk about our project" into "the AI can look up our project, under rules we set."

This guide explains what MCP is in plain terms, why it matters for construction data, how servers and gateways differ, what happens when an API has thousands of operations, how to govern it, and how to start without creating a new risk. It draws on the MCP servers and gateway we have built and published for Procore, Primavera P6, and multi-server tool routing.

MCP in plain terms

Before MCP, every AI integration was custom. If you wanted a chatbot to read Procore budgets, someone wrote glue code for that one chatbot and that one API. Switch models or tools and you started over.

MCP standardizes the connection. It defines how a client and a server talk (JSON-RPC messages over a transport), how a server describes what it can do, and how the client calls it. The full specification lives at modelcontextprotocol.io.

A useful mental model: MCP is to AI agents roughly what a standard plug is to appliances. The plug doesn't decide what the appliance does or whether it is safe. It just means you don't rewire the house for each one.

The core terms

Most of the value for construction sits in tools. Resources and prompts are useful, but tools are what let an agent actually query a budget or analyze a schedule.

Why MCP matters for Procore, P6, and ERP data

Construction data is spread across systems that were never designed to talk to each other: a project management platform, a CPM scheduler, an accounting ERP, a CRM, field tools, and a pile of spreadsheets that reconcile them. That fragmentation is exactly where people want AI help, and exactly where generic chatbots fail, because they can't see any of it.

MCP matters here for four reasons:

1. Live answers instead of pasted exports. An agent with Procore tools can call the API for the current project list or budget rather than working from a CSV someone uploaded last week.
2. One integration, many clients. Build the Procore server once and use it from a desktop assistant, an internal agent, or an automation. You aren't locked to one AI vendor.
3. A real boundary. Tools are explicit. You decide which operations exist, which are read-only, and which require approval. That is far easier to reason about than a model with a broad API token.
4. Observable behavior. Every tool call is a discrete event with inputs and outputs you can log, review, and use to improve the tools.

What MCP does not do: it doesn't clean your data, define your cost codes, reconcile your schedule to your ERP, or decide who should see what. Those are still integration and governance problems. MCP gives you a clean place to enforce the answers.

How an MCP tool call actually works

When a user asks an agent "What's the budget status on this project?", the flow looks like this:

1. The client connects to the MCP server and receives the list of available tools with their descriptions and input schemas.
2. The model reads the request and the tool list, then decides which tool to call and with what arguments.
3. The client sends the call to the server. The server authenticates to Procore with credentials it holds, makes the API request, and returns the result.
4. The model reads the result and either calls another tool (for example, budget line items after finding the project ID) or answers.

In our Construct.Chat demo, this is exactly what you see: the agent runs list projects, then the project details call, then a series of financial calls, and the platform logs each request, its parameters, and its response. That log is how we spot a failed tool, check whether an endpoint URL or required parameter changed, and fix it.

Step 1 is where large APIs get into trouble.

Servers vs. gateways

An MCP server wraps one system. A gateway sits in front of servers and controls access to them. Small setups only need servers. Production setups with multiple systems, teams, or customers usually need both.

Our Tool Runtime gateway is a working example. You select which MCP servers and which specific tools an API key can reach, set rate limits per key, and hand the resulting configuration to Cursor, Claude, or any client. Every call is logged with the organization, user, API key, server, input, and output, which makes debugging and review practical instead of theoretical.

You can also build gateway behavior into a large server. Our P6 MCP server includes its own gateway runtime with discovery, workflow planning, policy enforcement, approvals, audit logging, caching, rate limiting, and metrics in front of the P6 REST API.

Tool routing at scale: the problem with thousands of tools

Here is the issue most first MCP builds hit. Every tool's name, description, and schema is sent to the model as context. A handful of tools is fine. Thousands are not.

Generating one tool per endpoint from Procore's OpenAPI specs produced 2,755 tools in our Procore MCP server. Our P6 catalog covers 585 REST operations across 101 entities. Hand either list to a model and two things happen: the context fills with tool definitions before any work starts, and the model gets worse at picking the right tool.

The fix is routing. Instead of exposing every endpoint, you expose a small set of meta-tools that let the agent find what it needs:

• Discover: search the catalog by intent ("RFIs overdue on this project").
• Describe: get the full schema and dependencies for the few candidate operations.
• Plan: work out the order of calls, including which IDs must be fetched first.
• Call: execute through a single governed dispatch path.

In our Procore MCP, router mode reduces the 2,755-tool surface to roughly 25 meta-tools. Retrieval uses hybrid search (keyword plus embeddings, fused into one ranking) over the tools, capabilities, workflows, and policies, and a bandit tuner adjusts the ranking per tenant and persona. The server also supports an expanded mode (all tools, for clients that select tools themselves) and a hybrid mode where a persona or focus area, such as RFIs, pulls in only the relevant set.

The P6 server takes the same approach: 24 gateway tools for session context, discovery, planning, validation, execution, approvals, and audit sit in front of the 585 operations.

Routing has a second benefit: dependencies. Many construction API calls only work if you already have the right company, project, or object IDs. A catalog with dependency metadata lets the planner fetch them in order instead of letting the model guess.

The deeper write-ups are in routing 2,755 Procore API tools and the P6 MCP server.

Governance: what makes MCP safe to run against live data

An MCP server with write access to Procore or your ERP is a production integration that a language model can trigger. Treat it that way. These are the controls we build in by default:

• Credentials stay on the server. The model never sees a client secret or token. Clients authenticate to the server or gateway with their own key.
• Tenant isolation. In multi-organization setups, each organization's credentials are partitioned so no two organizations share tokens or reach each other's data. Both our Procore and P6 servers are built this way.
• Read-first scopes. Start with read-only tools. Add writes one workflow at a time.
• Policy on every call. Restrict deletes, require validation for creates, limit by environment (sandbox vs. production), and apply rate limits and quotas.
• Human approval for risky actions. The P6 server can preview a mutation and route policy-gated actions to a named user for approval before anything changes.
• A single dispatch chokepoint. In the Procore server, every call passes through one path: schema validation, rate limiting, policy, idempotency, the handler, output shaping, PII redaction, then audit. One path is one place to enforce and inspect.
• Telemetry you actually review. Log which tools were called, with what inputs, what came back, and what failed.

This maps to our design principles: least privilege by default, evidence on every output, and boring where it counts. For a fuller treatment, see governing AI agents in construction and our governance page.

Not every question needs a live API

One pattern worth copying: run analysis offline when you can. Our P6 MCP server includes 13 tools that work on an exported XER file with no live P6 connection: parsing, activities, critical path, resource use, schedule quality, WBS, relationships, calendars, schedule summary, and earned value.

A scheduler can export the file, point the agent at it, and get a schedule quality review without anyone issuing API credentials. The same server runs live REST tools alongside it when live access is warranted. For many teams, that is the right first project.

How to start: a practical checklist

1. Pick one question worth answering. "Which projects have budget changes this month?" or "Where is float eroding on this schedule?" A specific question beats "connect AI to Procore."
2. Map the systems and data it needs. Name the APIs, objects, and IDs involved. Note where systems disagree (job numbers, cost codes) because the agent will hit those gaps too.
3. Start read-only. Expose only the tools that question needs. No create, update, or delete yet.
4. Decide server, gateway, or both. One system and one team: a server. Multiple systems, teams, or clients: put a gateway in front.
5. Plan for API size. If the API has more than a few dozen operations, use discovery and routing rather than exposing everything.
6. Keep credentials server-side and isolated. Use the vendor's supported auth (for Procore, see developers.procore.com), a sandbox environment first, and per-organization separation.
7. Turn on logging from day one. Capture tool name, inputs, outputs, latency, and errors.
8. Test with real users and real questions. Review the logs weekly. Fix tool descriptions, add missing tools, retire unused ones.
9. Add writes deliberately. One workflow at a time, with validation, policy, and approval where the impact warrants it.
10. Deploy like any production service. Containerized, behind HTTPS, with health checks and metrics, using streamable HTTP for remote access.

Common mistakes

• Turning every endpoint into a tool. It works in a demo with five endpoints. With hundreds or thousands it fills context and degrades tool selection.
• Handing the model a broad token. If the server uses an admin credential for everyone, every user effectively has admin rights through the agent.
• Writes on day one. Start by proving the agent reads correctly. Then add carefully scoped writes.
• No logs. Without a record of tool calls, you can't debug failures, prove what the agent did, or improve it.
• Assuming MCP fixes the data. If Procore and the ERP disagree about a job's committed cost, the agent will surface that disagreement, not resolve it. Fix it at the source or flag it explicitly.
• Hand-writing hundreds of tools. Generate them from the vendor's OpenAPI spec so they stay current when the API changes.
• Treating the local desktop setup as production. A stdio server on one laptop is fine for exploration. Shared use needs a hosted server with auth, isolation, and monitoring.

How we approach it

We have built and published the patterns in this guide, and the details are in our demos and repos:

• Procore MCP architecture: 2,755 tools generated from Procore's OpenAPI specs, five layers (transport, mode, resolver, dispatch, generated clients), router mode with about 25 meta-tools, capabilities, workflows, personas and policies, multi-tenant headers, and a single governed dispatch path.
• Primavera P6 MCP server: 585 operations across 101 entities generated from the OpenAPI spec and scraped P6 docs, a gateway runtime with discovery, YAML workflow playbooks, approvals and audit, plus 13 offline XER tools.
• Tool Runtime gateway: a registry of MCP servers, per-key selection of servers and tools, rate limits, and input/output telemetry on every call.
• Construct.Chat agents: an agent using Procore MCP tools on live project and financial data, with every tool call logged for debugging and improvement. More on that in construction AI agents with MCP tools.

A few principles carry through all of them. We generate tools from the source spec instead of hand-writing them. We route instead of dumping the full tool list into context. We keep credentials server-side and partitioned by organization. We put policy and audit on one dispatch path. And we start read-only, with telemetry on from the first call.

For most construction teams the best first project is narrow: one system, one set of read-only questions, a sandbox, and logging. Once that is trustworthy, adding the next system or the first write workflow is a small step. Many of these builds are public on our GitHub repos page, and the wider set of agent guides is under agents.

Where to go next

• Watch the Procore MCP architecture walkthrough to see routing across 2,755 tools.
• Read how we built the Primavera P6 MCP server, including offline XER analysis.
• Read governing AI agents in construction before putting agents on live data.
• Have a system you want agents to work with safely? Tell us what you want to build.