A manufacturing engineer spends part of a shift not on engineering work but on searching: where the current procedure version is stored, what the error code is on line 4, why the cycle increased over the last 100 units, what the order status is in ERP. The data exists, but it is spread across MES, SCADA/the historian, ERP, and PDF instructions with different interfaces and access rights. Anthropic's open Model Context Protocol (MCP) lets these systems be wrapped into a single protocol that an AI agent can connect to. Below is an overview of what can already be built with this approach, based on public examples. This is not a KT.Team case study, but an analysis of open implementations.
What MCP is and why it fits manufacturing
MCP is an open standard that defines a unified way to connect LLM applications to external data and tools (modelcontextprotocol.io). Instead of a set of custom point-to-point integrations, one protocol appears with two types of capabilities: resources — read-only access to data sources, and tools — actions that change system state. This distinction matters on the shop floor: line monitoring and history lookup go through read-only resources, while any control action goes through an explicitly defined tool with permissions (Inductive Automation).
The business result is direct: an engineer and an operator ask a question in natural language and get the answer from the right system without switching between MES, the historian, ERP, and an instruction folder. Time to find an answer drops from minutes spent navigating interfaces to a single query.
Wrap MES: line questions instead of dashboard navigation
The Tulip platform released an open-source MCP server that exposes key manufacturing entities - tables, machines, stations, users - as tools that models can understand (Tulip). An operator asks, “What is the average cycle time for the last 100 units on line 4?” or “Which stations reported downtime during the last shift?” and gets an answer without manually building a report. Each tool response carries structured metadata, so the model understands what the data represents instead of getting raw numbers.
Access is restricted through API tokens: the vendor defines what the agent can read and change. The server runs locally or is deployed for continuous use and connects to MCP-compatible clients.
Real-time line state: SCADA via MCP
Inductive Automation is developing an MCP module for the Ignition platform that will give AI systems access to the capabilities and data available through Ignition's scripting engine - tags, line status, historical data (Inductive Automation). The key principle is that operators get read-only access to line state and history through resources, while control actions are moved into separate tools with permissions for engineers. This lets the agent ground its answer in current production data, not stale training-set knowledge.
Wrap ERP: order status and business logic without custom APIs
The same approach applies to ERP. The Dynamics 365 ERP MCP server gives agents three categories of tools: data tools (CRUD over data entities via OData and SQL), form tools (navigating forms the way a person would) and action tools (direct invocation of business logic in code) (Microsoft Learn). Crucially, context is updated dynamically based on the user role: if the agent is working as a Purchasing Agent, it receives only the objects available to that role. The system rejects calls to objects the role cannot access, so permissions and audit inherit from the ERP rather than being rebuilt from scratch.
For SAP, there are public open-source MCP servers: hana-mcp-server for SAP HANA and CDataSoftware/sap-erp-mcp-server-by-cdata for read-only access to SAP ERP data. In other words, ERP can be wrapped in MCP using ready-made solutions, without building the integration from scratch.
Wrap technical documentation: procedure for an error code
The third source is technical documentation and procedures (SOPs). Here, the MCP server encapsulates the RAG pipeline: documents are split into chunks, embedded, and loaded into a vector database (FAISS, Weaviate, Pinecone), and the agent is given a single semantic search tool (Scaler). Open-source MCP SOP server gives agents semantic search across categorized collections of procedures. In a manufacturing scenario, a technician enters the machine error code, and the system synthesizes an answer from technical manuals, past repair logs, and technician notes, returning diagnostic steps and a resolution.
KT.Team's approach to this kind of integration
A mature implementation follows the principle of minimal core modification: MES, SCADA, ERP, and the document repository are not forked or patched; MCP servers live alongside them as a thin layer that reads and calls existing APIs. Permissions and audit inherit from the source systems (as in Dynamics 365, where the role limits context) rather than being duplicated. Read-only resources are separated from control tools so the operator cannot accidentally change line state. International open standards (MCP, OData) are used instead of custom-built connectors, and loose coupling provides portability: the server can be handed to another team or the client agent can be replaced without rewriting the integration.
Business process outcome
Wrapping MES, ERP, and technical documentation in MCP changes how information is retrieved on the shop floor: instead of “find the system → log in → build a report → find the PDF,” the engineer and operator ask once, and the agent queries the right source while respecting access rights. Diagnostic downtime is reduced, dependence on whoever “knows where everything is” goes down, and permissions and audit stay on the source systems’ side. Start with read-only scenarios (line state, order status, procedure lookup) and expand to control actions as access control matures.
