MCP and the connected construction office
The Model Context Protocol is a standard way for AI models to connect to tools and data sources. It matters because it collapses the cost of connecting an assistant to your systems, which moves automation that only made sense on a Tier 1 budget into reach for a regional contractor. It is an open specification rather than a vendor product, which is the whole point: you are not buying a connector, you are adopting a convention that several vendors already implement.
You do not need to understand the engineering. You need to understand what it changes.
What problem does MCP actually solve?
Custom wiring. Until recently every integration between an AI and a tool had to be purpose-built, one connection at a time: expensive, fragile and slow.
| Before a standard | With MCP | |
|---|---|---|
| Connecting an AI to SharePoint, Outlook and a cost system | Three bespoke integrations | One socket shape, three connections |
| Cost of adding a fourth system | Another bespoke build | Marginal |
| What the assistant can do | Reason about what you paste in | Read the folder, search the inbox, query the tracker, write the update back |
| Who could justify it | Large organisations with a development budget | Any business with a workflow worth automating |
| When the vendor changes | Rebuild the integration | The socket is unchanged |
Think of it like the USB standard. Any tool that speaks it can plug into any AI that speaks it. Until it existed, an AI assistant was a very well-read colleague locked in a room with no phone: it could reason about anything you handed it, but it could not look anything up or do anything on its own.
What does that look like on a real workflow?
Take a drawing arriving by email. A connected assistant reads the transmittal, files the drawing to the right location with the right name, updates the drawing register, checks whether the revision supersedes anything in the current package, and drafts the notification to the affected trades. Six systems touched, no human clicking between them.
Or the Monday report. It pulls progress from the site record, costs from the tracker and programme status from the planner's export, opens last week's report as the template, and produces this week's draft with changes highlighted. The PM edits judgement rather than formatting.
Neither was impossible before. Both were bespoke every time, which is the difference between owning software and having it actually connected.
What caution comes with it?
An AI that can reach into your systems is powerful in both directions, so the guardrails matter more rather than less.
Access scoped to exactly what each workflow needs. Every action logged and auditable. Anything leaving the business or carrying contractual weight goes through a person. And the whole arrangement inside your environment under your identity controls, not on somebody's personal account, which is the same public-versus-private question with higher stakes attached.
The standard is still maturing, and it is not the only way to connect systems. Conventional APIs and automation platforms still carry plenty of the load. The direction, though, is set.
Why does this favour firms that prepared?
Because connected AI amplifies whatever it is connected to, in both directions.
A clean SharePoint, consistent naming and a structured project record, and the assistant flies. A decade of unstructured folders, and the assistant faithfully retrieves chaos, faster than ever. The protocol does not fix your filing, it removes the excuse for not fixing it.
Which is why the advice has not changed since before any of this existed. Sort the data foundations, capture the records as they happen, structure the information. Every improvement made there now pays twice: once immediately, and again for every connected workflow switched on later. The businesses whose information is ready will feel like they got a head start, because they did.