AI in Maintenance

MCP Protocol and AI Maintenance Tools: Building Connected Systems

January 29, 202611 min readDovient Learning

You have a CMMS that holds your work orders. A historian that stores sensor data. An ERP system that manages spare parts inventory. A document management system with your SOPs. A vibration analysis platform. An oil analysis portal. A thermal imaging database. Each one of these systems knows something about your equipment, but none of them talk to each other in any meaningful way.

When a technician needs to diagnose a problem, they log into 3-4 systems, copy-paste data between screens, and manually piece together the picture. When a reliability engineer wants to understand a failure pattern, they export CSVs from multiple systems and stitch them together in a spreadsheet. The data exists. The connections between that data do not.

MCP (Model Context Protocol) changes this. It is a standard way for AI tools to connect to your existing systems and use them together. Instead of the technician going to each system one by one, the AI goes to all of them simultaneously, pulls the relevant information, and presents a complete picture. This article explains what MCP is, why it matters for maintenance, and how it works in practice.

What Is MCP?

MCP stands for Model Context Protocol. It is an open standard, developed by Anthropic (the company behind Claude AI), that defines how an AI model connects to external tools and data sources. Think of it as a universal adapter. Just as USB-C lets you plug any device into any computer without worrying about the specific connector, MCP lets an AI connect to any software system without requiring custom integration for each one.

Before MCP, every connection between an AI and an external system required custom code. Want the AI to read from your CMMS? Write a custom integration. Want it to also read from your historian? Write another custom integration. Want it to check parts inventory? Another integration. Each one is different, fragile, and expensive to maintain.

With MCP, each system exposes its capabilities through a standard interface. The AI knows how to speak MCP. Your CMMS has an MCP adapter that knows how to translate MCP requests into CMMS queries. Your historian has an MCP adapter that knows how to serve sensor data. The AI does not need to know the specifics of each system. It just speaks MCP, and the adapters handle the translation.

Why MCP Matters for Maintenance AI

Maintenance AI is only as good as the data it can access. An AI that can read your work orders but not your sensor data is working with half the picture. An AI that can read work orders and sensor data but not your SOPs cannot provide repair instructions. The value of maintenance AI increases with every additional data source it can access.

MCP matters because it makes those connections practical instead of theoretical. Without MCP, connecting an AI to 5 systems means 5 custom integrations, each costing weeks of development and ongoing maintenance. With MCP, connecting to 5 systems means deploying 5 standard adapters, each following the same pattern.

The specific maintenance scenarios where connected AI tools make a difference:

  • Diagnosis. The AI reads the work order description, pulls the equipment's sensor data from the historian, checks the repair history in the CMMS, looks up the relevant SOP, and checks parts availability. All in one query. The technician gets a complete diagnosis with repair steps, safety warnings, and parts status. For more on how this diagnosis process works, see our AI-powered repair diagnostics guide.
  • Failure prediction. The AI monitors sensor data from the historian, compares it against failure patterns learned from CMMS work order history, and generates a work order when it detects a developing problem. The prediction, the evidence, and the recommended action all flow through connected systems.
  • Knowledge retrieval. A technician asks "What is the torque spec for the coupling bolts on Compressor C-301?" The AI searches the document management system for the OEM manual, the CMMS for past work orders that mention those bolts, and the tribal knowledge base for any technician notes. It returns the answer with sources from all three systems. See our natural language search article for how this semantic retrieval works.
  • Reporting. A manager asks "What is the total cost of compressor maintenance this year?" The AI queries the CMMS for work orders, the ERP for parts costs, and the labor management system for technician hours. It returns a complete cost breakdown without anyone building a custom report.
MCP Architecture: AI Connected to Maintenance Systems Technician / Engineer Asks a question in natural language AI Model (Claude / LLM) Understands the question, decides which tools to call MCP Protocol Layer (Standard Interface) MCP Adapter MCP Adapter MCP Adapter MCP Adapter MCP Adapter CMMS Work orders, PM schedules Historian Sensor data, process values Document Mgmt SOPs, manuals, tribal knowledge ERP Parts inventory, procurement CBM Platform Vibration, oil, thermal analysis How it works in practice: Technician asks: "Why is Pump P-107 vibrating high?" AI calls CMMS (repair history) + Historian (vibration trend) + Docs (OEM specs) + ERP (parts stock) Returns: diagnosis + evidence + repair steps + parts availability in one response

How Tools Connect Through MCP

MCP defines three things: what a tool can do, how to ask it to do something, and what format the results come back in. Each tool (each system in your maintenance stack) registers its capabilities with the AI.

For example, a CMMS MCP adapter might register these capabilities:

  • get_work_orders - retrieve work orders filtered by equipment, date range, status, or work type
  • get_equipment_history - retrieve complete maintenance history for a specific asset
  • create_work_order - create a new work order with specified details
  • get_pm_schedule - retrieve upcoming preventive maintenance tasks

A historian MCP adapter might register:

  • get_sensor_data - retrieve time-series data for specific tags and date ranges
  • get_current_values - retrieve the latest reading for specified sensor tags
  • get_alarm_history - retrieve alarm events for equipment or sensor tags

When the AI receives a question like "Why is Pump P-107 vibrating high?", it decides which tools to call based on the question. It calls get_sensor_data on the historian to see the vibration trend. It calls get_equipment_history on the CMMS to see past repairs. It calls a document search tool to find the relevant SOP. It calls get_current_values on the ERP adapter to check if replacement bearings are in stock. All of these calls happen through the same MCP interface.

The AI does not need custom code for each system. It speaks MCP. The adapters translate. New systems can be added by deploying a new adapter without changing the AI or any existing adapters.

Dovient's MCP Compatibility

Dovient's MissingDots platform supports MCP natively. This means it works with Claude (Anthropic's AI) and any other AI tool that supports the MCP standard. The practical implications:

  • Your data stays in your systems. Dovient does not require you to migrate data out of your CMMS, historian, or ERP. The MCP adapters connect to your systems where they are. Your data stays under your control, in your security perimeter.
  • Add systems without rebuilding. When you add a new data source (a new CBM platform, a new document repository), you deploy an MCP adapter for that system. The AI automatically gains access to the new data. No reconfiguration of the AI, no changes to existing adapters.
  • Use Claude for maintenance tasks. Because Dovient supports MCP and Claude supports MCP, you can use Claude as your maintenance AI assistant with full access to your plant's data through Dovient's adapters. Ask Claude a maintenance question, and it pulls the answer from your actual systems.
  • Not locked to one AI provider. MCP is an open standard. If you want to switch from Claude to a different AI model tomorrow, the MCP adapters still work. Your investment in connecting your systems is protected regardless of which AI you use.

Building Connected Maintenance Workflows

Individual tool connections are useful. Connected workflows are transformational. Here is what becomes possible when your maintenance AI can talk to all your systems simultaneously.

Workflow 1: Predictive to Planned

The historian detects an anomaly in the vibration data on Motor M-203. The AI queries the CMMS for similar past failures on this motor model. It finds that this pattern has preceded bearing failure in 4 previous cases, with an average lead time of 3-5 weeks. It checks the ERP for bearing availability: 2 in stock. It checks the maintenance schedule for planned downtime: a line shutdown is planned in 2 weeks. The AI generates a work order: "Replace bearings on Motor M-203 during planned shutdown on April 5. Parts: Bearing SKF 6310, Qty 2, in stock. Estimated time: 3 hours based on similar past jobs." The planner reviews and approves. No human had to log into 4 systems and piece this together. For a deeper look at the ML models behind this kind of detection, see our guide to machine learning for predictive maintenance.

Workflow 2: Diagnosis with Full Context

A technician types: "Compressor C-301 is tripping on high discharge temperature." The AI pulls the last 48 hours of discharge temperature data from the historian. It pulls the maintenance history from the CMMS and sees that the aftercooler was cleaned 6 months ago. It searches the document system for the aftercooler cleaning procedure and the normal temperature range from the OEM manual. It checks the process data to see if inlet conditions have changed. The response: "Discharge temperature has risen from 185F to 220F over the past 2 weeks (trend attached). The aftercooler was last cleaned on October 15. Based on the cleaning interval and temperature rise pattern, the aftercooler is likely fouled. The OEM recommended cleaning interval is 4 months for this duty. Recommended action: clean aftercooler per SOP-C301-AC-CLEAN. Parts needed: gasket set GK-AC-301, in stock."

Workflow 3: Failure Analysis Across Systems

A reliability engineer asks: "What are the top 5 failure modes driving unplanned downtime on the ammonia system this year?" The AI queries the CMMS for all corrective work orders on ammonia system equipment in the current year. It calculates downtime hours from the work order data. It checks the historian for related sensor alarm data. It cross-references with the FMEA (if one exists in the document system) to see which failure modes are already being addressed by the PM program. The response is a ranked list of failure modes with downtime hours, frequency, cost, and whether each one has an existing PM task or condition monitoring strategy. If you want to take this analysis further into a structured FMEA, our AI-generated FMEA guide explains how.

Connected Maintenance Workflows via MCP AI + MCP Central Intelligence Prediction Detect anomalies early Diagnosis Identify root cause Work Orders Auto-generate & enrich Parts Mgmt Check & reserve stock Analytics Failure trends, costs FMEA Auto-generate & update Knowledge Base SOPs, manuals, tribal Scheduling Optimize timing Each workflow calls multiple tools through MCP. No custom integration per connection. Add new tools without rebuilding.

MCP vs Traditional API Integration

If you have experience with software integration, you may be thinking: "This sounds like an API. We already have APIs." MCP is related to APIs but solves a different problem.

Traditional API integration connects two specific systems: your CMMS talks to your ERP, your historian talks to your dashboard, etc. Each connection is point-to-point. If you have 5 systems and want them all connected, you need up to 10 point-to-point integrations. Each one is different. Each one breaks when either system updates.

MCP creates a hub-and-spoke model with the AI at the center. Each system connects to the AI through a standard MCP adapter. 5 systems = 5 adapters. The AI handles the orchestration: deciding which systems to query, combining the results, and presenting a unified answer. When a system updates its API, only its MCP adapter needs updating. The AI and all other adapters are unaffected.

Dimension Traditional API Integration MCP
Architecture Point-to-point between systems Hub-and-spoke with AI at center
Connections for 5 systems Up to 10 custom integrations 5 standard adapters
Adding a new system New integrations to each existing system One new adapter
Intelligence Pre-programmed data flows AI decides what to query based on context
Maintenance burden High (each integration is custom code) Lower (standard adapters, shared protocol)

Security and Data Control

A reasonable concern: "If the AI can access all our systems, what about security?" MCP addresses this with built-in access controls.

  • Role-based access. The MCP adapter for each system respects that system's existing access controls. A technician using the AI gets the same access to the CMMS that they would get logging in directly. A manager gets their level of access. The AI does not bypass permissions.
  • Read vs write controls. Each adapter can expose read-only or read-write capabilities. You might want the AI to read work orders from the CMMS but not create them automatically, at least initially. You configure this at the adapter level.
  • Audit logging. Every MCP call is logged: what system was queried, what data was accessed, which user initiated the request. You have a complete audit trail of what the AI accessed and when.
  • On-premise deployment. MCP adapters can run entirely within your network. Your data does not need to leave your premises. The AI model can be cloud-based (for best performance) or on-premise (for maximum data control), depending on your requirements.

Getting Started with MCP

You do not need to connect everything at once. Start with the highest-value connections and expand from there.

  1. Connect your CMMS first. Work order history is the single most valuable data source for maintenance AI. It feeds diagnosis, failure analysis, and work order planning. Start here.
  2. Add your document system. SOPs, manuals, and tribal knowledge are the second most valuable. They give the AI the ability to provide repair instructions and safety warnings alongside diagnosis.
  3. Add your historian or CBM platform. Sensor data enables predictive maintenance and adds quantitative evidence to diagnoses. This is where the prediction workflows start working.
  4. Add your ERP or parts system. Parts availability checking completes the work order workflow. The AI can tell a technician not just what is wrong and how to fix it, but whether the parts are available right now.
  5. Add additional sources as needed. Scheduling systems, labor management, safety databases, training records. Each new connection makes the AI more capable without requiring changes to existing connections.

Where Dovient Fits

Dovient's MissingDots platform is built on MCP from the ground up. It ships with pre-built MCP adapters for common maintenance systems (SAP PM, Maximo, eMaint, common historians, major ERP platforms) and supports custom adapters for proprietary systems.

Because Dovient uses MCP natively, it works with Claude and other AI tools that support the protocol. Your maintenance team can interact with the AI through Dovient's own interface, through Claude directly, or through custom applications that speak MCP. The data connections remain the same regardless of which interface you use.

To see how MCP-connected maintenance AI works with your plant's systems, schedule a conversation with our team.


Related Articles