FacilityConnect now has an MCP server. Point an AI assistant at it and it can list your projects, walk a scenario's assets and connections, find the nearest supply points to a location, and load structured rows into the model. The connection itself is the easy part. What took the work was deciding what the server should refuse to do on its own.
MCP — the Model Context Protocol — is the emerging standard for letting an assistant use a system's real functions instead of guessing from a screenshot. Plenty of products have shipped one by wrapping their REST API and calling it done. That approach is exactly wrong for a utility model.
A write that cannot quietly go wrong
The bulk upload is the clearest example. It takes assets and their components — demand POCs, distribution POCs, nodes, services — and upserts them into a scenario. It is the same path as the Excel upload in the UI, with the same validation behind it.
It defaults to preview mode. The server runs the entire upload, collects every error and warning, rolls the whole thing back, and returns a summary of what would have been created or updated. An assistant is expected to show that summary and wait for a person to agree before committing. Writing without previewing is possible, but it is the deliberate second step, not the default.
An agent that can write to your model without showing you the diff first is not a feature. It is an incident waiting for a calendar slot.
Two more properties matter as much. The upload is atomic: if any row fails validation, nothing is written and the errors come back instead of a half-loaded scenario. And it is an upsert, so re-sending a chunk after a timeout is safe rather than a way to create duplicates. Large loads chunk at five hundred rows, laterals before tools, parents before children — the ordering the model needs to resolve connections.
It speaks the model, not the database
The tools are shaped around how the model actually works rather than around its tables. Listing projects returns each one's baseline scenario — the Live scenario — because that is what you want unless you are deliberately working in a named alternative, and an assistant that doesn't know this will cheerfully edit the wrong one.
The nearest-supply-point lookup returns the same ordered list the assignments page shows, so an assistant answering "what could serve this tool?" and an engineer looking at the screen get the same answer. Capacity limits come back in the utility type's own unit. Coordinates are metres in the project frame.
The bulk upload takes names, not identifiers: a utility type, a building, a level, an asset's upstream component, all written the way they appear in the project. A person reviewing a proposed upload can read it. That is not a convenience — it is what makes the preview worth showing.
What this is actually for
Three things, mostly. Asking questions of a model that is too large to eyeball: which demands on this level have no upstream connection, what is the spare capacity on this system, what changed between two revisions. Getting data in from a format nobody wants to hand-map. And the loop in between — load, check, correct, re-run — where the tedious part was never the thinking.
It is the same loop FacilityConnect has always run, and the same one your engineers now run themselves. The MCP server just means the assistant sitting next to them can see the model too, with the capacity rules and the validation intact rather than reasoning about a spreadsheet.
Write access is still gated on project permissions, and nothing here bypasses them. An assistant can only do what the person it is acting for could already do — which is the only sane starting position for a system that sizes a fab's utility backbone.