Build Flows

MCP servers for Procore, Primavera P6 and other construction systems

An MCP server exposes a construction system's API as tools an AI agent can call, with scoped permissions and a log of every call.

The problem

Teams want Claude, Copilot or their own agents to answer questions about live project data, but the model knows nothing about your projects and the systems that do have large, complicated APIs. Handing an agent broad credentials is not acceptable, and a demo that works once is not something you can run.

What we build

We build a Model Context Protocol server around the system's API, choose the tool set deliberately (read-only first), and route calls through a gateway that injects credentials and logs every request and response. Agents get exactly the tools their job needs, and failed calls are visible before users notice. We have shown this pattern with Procore and Primavera P6.

How it works

  1. 1

    Pick the job and the tools it needs

    We start from the questions or tasks the agent must handle and map them to the API operations required, so the tool set is the permission boundary.

  2. 2

    Build the server

    We wrap the API as MCP tools with clear names, descriptions and input schemas, organized so the server stays maintainable as the vendor API changes. For large APIs we add tool discovery and routing so the model sees only relevant tools.

  3. 3

    Govern access

    Credentials are injected by the server or gateway, never given to the model. We default to list and read tools, add a safe offline path where it helps (such as XER analysis for P6), and add write tools only with approval steps.

  4. 4

    Log, test and deploy

    Every tool call is recorded with parameters, response and success or failure. A verification script runs live checks, and the server is hosted over streamable HTTP or run locally for the agents you use.

  • Procore
  • Oracle Primavera P6 and XER files
  • Salesforce
  • ArcGIS
  • Model Context Protocol (MCP)
  • Claude, Claude Code, Codex and other MCP clients
  • TypeScript and Python

The value it creates

  • Time saved

    Measured by timing a set of real lookups done by hand in the source system against the same questions answered by an agent using the server.

  • Visibility

    Per-call telemetry shows which tools are used, how often and where calls fail, so the integration is observable instead of a black box.

  • Standardization

    One governed server gives every agent the same tools and permissions, instead of each team wiring its own credentials and scripts.

  • Collective intelligence

    Agents in different tools reach the same live project data through one server, so answers come from the system of record rather than exported copies.

Proof

Frequently asked questions

What is an MCP server?

The Model Context Protocol is an open standard for giving AI models a defined list of tools. An MCP server wraps a system's API as those tools, so an agent in Claude, Claude Code, Codex or another MCP client can call them. The tools you include are the limit of what the agent can do.

Is it safe to connect an AI agent to Procore or P6?

It can be, when access is designed rather than assumed. We start with read-only tools, keep credentials out of the model, log every call, and add write actions only with a person approving them. A client deployment still needs its own access review and testing.

Can you build an MCP server for a system that is not on your list?

Yes, if it has an API we can access. We have built servers for Procore, Primavera P6, Salesforce, ArcGIS, weather and OCR services, and an OpenAPI-to-MCP tool that starts from an API specification. Discovery confirms the API, versions and access first.

Are your MCP servers open source?

Several are published on our GitHub, including the Procore and P6 servers and the Tool Runtime gateway. Servers built for a client are scoped and owned under the terms agreed for that engagement.

Next step

Which report or workflow would you like to improve?

Tell us what your team does today, which systems are involved, and what you want to change. We'll discuss whether there is a practical fit.

Prefer email? charley@buildflows.ai