We're Building an MCP Server for AssetOS
Every maintenance manager I have worked with has the same Tuesday morning.
Log in. Find the report. Set the date range. Set the site filter. Export it. Realise you wanted it grouped by asset class instead, and do the whole thing again.
I have spent 18 years building software, eight of them on asset management systems at Thales and Hitachi Rail. In all that time, the answer to "which pumps missed their PM last month" has never stopped going through the reporting screen.
So we are building an MCP server for AssetOS. It is in build, not shipped, and there is a waitlist for early access. I want to write down what it is and what it isn't while it is still being built, because that is the honest time to do it.
What MCP actually is
The Model Context Protocol is an open standard for connecting AI assistants to real systems. An MCP server exposes a defined set of tools that an assistant is allowed to call, and never anything beyond that list.
We are not adding an "AI assistant" button to the corner of our app. The assistant your team already uses connects to AssetOS and reads your actual records, through a connection you authorise.
For us that means the assistant asks AssetOS for open work orders, or the PM schedule for the next fortnight, or the service history on a specific asset. AssetOS returns the records. The assistant does the reading.
What changes
Today, getting an answer means logging into the portal, finding the right report, setting the filters, exporting to a spreadsheet, and repeating all of it for the next question. With the MCP server, you ask the question and the follow-up in the same conversation.
Your data stays where it is. The distance between having a question and having the answer gets shorter.
Most of the questions a supervisor has never get asked, because a trip through the reporting screen costs more than the answer is worth. Make asking cheap and the third and fourth questions get asked too. Those are the ones that find the problem.
Version one is read-only, on purpose
The MCP server will answer questions. It will not create work orders, close them, reassign them or delete anything.
We could ship write tools in version one. We are not going to. An assistant that closes the wrong work order at 2am does more damage than no integration at all. It corrupts the one thing a CMMS exists to protect, which is the record of what actually happened to the asset. Write tools will come, with their own scopes and their own consent step, once the read side has been used in anger by real teams.
There is a second reason. Nobody yet knows which questions maintenance teams will actually ask an assistant. We have a list, and it is a guess. Early access exists to replace that guess with evidence before we design anything that writes.
It signs in as you, and only as you
There is no service account and no shared API key quietly reading the whole tenant.
Each person connects with their own AssetOS login over OAuth, the same consent pattern as our Slack and Teams integrations. The server inherits that person's role. If your account cannot see the Warrington depot, neither can your assistant. Disconnect from AssetOS and access stops immediately.
If you are evaluating anyone's AI integration, ask where the permissions come from. If the answer is a key in a settings page rather than the user's own identity, you have granted an assistant more access than the person using it.
Where your data goes, said plainly
When you ask a question, the records our server returns go to the AI assistant you connected. That is how it answers. There is no version of this where the assistant helps without seeing the data.
If a vendor tells you their AI integration never shows your data to the AI, ask them what the AI is reading.
What we can tell you is the shape of it. You choose the assistant. AssetOS does not call a model on your behalf — the server returns your records and stops. We do not train any model on your data. And if sending asset data to an assistant provider is not acceptable in your organisation, this integration is not for you, and our REST API is.
What it won't do in version one
- Create or close anything. Read-only, as above.
- Log every question to the audit trail. Our audit trail covers work orders and asset changes as it always has. Per-question logging for assistant reads is on the list and is not in version one. I would rather write that here than let you assume it.
- Make the assistant's answer our answer. We return your records accurately. How an assistant summarises them is the assistant's behaviour. For anything you are putting your name to, open the record.
- Be useful without an assistant. If your team doesn't use one, nothing here is a reason to start.
The data is already reachable today
The MCP server changes who can ask and how fast. It is not what makes the records available.
The REST API is live and gives you full read access to assets, work orders and schedules. Webhooks push events as they happen. Slack and Microsoft Teams are live, so alerts land in the channel your team already watches with acknowledge, comment and close on the message itself.
If you are still running maintenance on a spreadsheet, none of this is your first problem — getting the history into one place is. A spreadsheet answers exactly one question well: the one you built the tab for. Every new question is a new pivot table, and when the person who built it leaves, the answers leave with them.
Early access
The AssetOS MCP server is in build. No date promised yet. When it is close, the people on the list hear first, and the questions they ask will decide which tools version one ships with.
Shane Price
Writing about maintenance management, CMMS implementation, and the real challenges operations teams face.