Procore MCP Server

Plain-language explanation of what the MCP server does and how it works with Procore: that it is an MCP server we host, that it exposes tools an AI assistant can call against the customer's Procore data, and what a customer gets out of it. Name the Procore data it touches (RFIs, submittals, daily logs, …) and state plainly that a person stays in the loop for anything that writes.

What the customer needs on hand: a Procore account and the permissions required to install an app, which Procore tools must be enabled, any Icefield-side account or key, and the supported MCP clients (Claude Desktop, Claude Code, Cursor, …) with minimum versions.

Numbered, click-by-click install steps with screenshots — Marketplace install and the custom-app install flow (App Version Key) for customers who install directly. This is the content Procore's reviewer checks against the manifest's post-install instructions, so it has to match what the app actually does.

How to point an MCP client at our server: the server URL, the transport, how authentication works and where the customer gets their credentials. Include a copy-pasteable config block per supported client and a first call to run to confirm the connection is live.

A table of every tool the server exposes — name, what it does, whether it reads or writes, and which Procore permissions it needs. Keep it current as tools are added; Procore requires documentation to stay accurate after launch.

Which Procore permissions the app requests and why, what data leaves Procore, where it is processed and how long anything is retained. Link the privacy policy and terms. Be specific — this is what a customer's IT reviewer will read.

A symptom / cause / fix table for the failures we actually expect: authentication rejected, no company or project resolved, tools not appearing in the client, permission errors from Procore, and the sandbox vs production base URLs.