Revizto opens construction data to AI via API and MCP server

Revizto has started exposing its project data to third party AI platforms through two new pieces: an API and its own MCP server. The news comes from AEC Magazine, and the signal is a concrete one: the Model Context Protocol is moving beyond developer tooling and into vertical software for industries that rarely show up in these conversations, such as architecture, engineering and construction.

It helps to be clear about which data we are talking about. Revizto is a coordination platform: it aggregates models from different disciplines, helps detect clashes and manages the issue workflow between office and site. That issue history, with its author, its discipline, its location in the model and its status, is exactly the kind of information that today gets checked by hand or by exporting reports. Opening it through an API changes who can read it. Opening it through MCP changes how.

What the MCP server adds on top of the API

An API is a call surface that somebody has to program against. MCP is Anthropic's standard for letting a model discover the available tools and invoke them with the user's permissions, without a custom integration per client. In practice, a coordination lead can ask for a summary of open MEP issues from the past week and the assistant calls the matching tool, instead of waiting for someone to put the report together.

The difference is not cosmetic. With the API, every integration requires its own development work and maintenance every time the vendor changes something. With MCP, the vendor writes the connector once and any compatible client benefits from it, whether that is Claude Desktop, Claude Code or an internal agent built on the same specification. It is the move software issue trackers already made, except here the starting point is a federated construction model rather than a repository.

Why it matters outside construction

The MCP server catalogue has grown mostly in the predictable band: repositories, databases, documentation and cloud services. Sectors with proprietary software, per seat licences and long purchase cycles lagged behind. An AEC vendor shipping an official server, rather than a community wrapper maintained by an integrator, suggests the protocol is starting to be treated as a product interface and not a lab experiment.

For anyone building internal agents, this removes part of the thankless work: no longer propping up brittle connectors against APIs that shift without warning. But expectations need calibrating. An MCP server is worth exactly what its tools are worth. If it exposes three read endpoints with no filters, the assistant will drag noise into context and the result will be worse than a well written database query. What makes the difference are filters by project, discipline, date and status, plus a permission model that respects the roles already defined in the platform. An intern should not be able to read through MCP what they cannot read through the interface.

Who this is useful for

Coordination leads and BIM managers who spend hours preparing issue reports that nobody reads in full.
Contractor data teams who want to cross issues with scheduling or cost without building an ETL for every query.
* Developers already running agents in Claude Code who need site context without writing a client from scratch.

The detail is still pending, and that is where this gets decided: which tools the server exposes exactly, at what permission granularity, with what usage limits and with what call traceability. The AEC Magazine piece confirms the piece exists, and the documentation will tell the rest once it is published.

Our reading is that the relevant part is not that Revizto added AI, but that it chose MCP as the entry point instead of an embedded chatbot: that decision leaves the customer deciding which model to use and with which permissions. We would like to see the same criterion across the rest of vertical software, provided it comes with clear scopes and call auditing.