What is Model Context Protocol (MCP) in Manufacturing?

The AI Dilemma in Manufacturing

The industrial sector is caught in a paradox. On one side, executives and engineers are eager to leverage Large Language Models (LLMs) like ChatGPT, Claude, and Gemini to analyze production bottlenecks, triage maintenance alerts, and generate shift handover reports. On the other side, OT (Operational Technology) and Cyber Security teams share a collective operational burden: What if a hallucinating AI accidentally writes a command to a PLC and stops the entire production line?

In manufacturing, AI cannot be given unfettered access to control systems. The risks of unexpected setpoint changes, safety interlock overrides, or high-impact downtime are simply too great.

This is where the Model Context Protocol (MCP) enters the picture, bridging the gap between cutting-edge AI assistants and secure, mission-critical industrial networks.

• Scoped: AI access follows approved tool contracts
• Separated: AI data path and machine control path

Outcomes depend on workload profile, hardware capacity, and deployment topology.

What is Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open protocol for connecting AI applications to data sources and tools. MCP standardizes discovery and invocation; it does not provide security by itself. Identity, authorization, input validation, network boundaries, audit, and human approval remain responsibilities of the implementation.

In a standard IT environment, an MCP server might expose approved enterprise data tools. In manufacturing, an implementation can expose scoped machine telemetry, Unified Namespace data, or maintenance records without giving the AI client direct credentials to the underlying PLC, SCADA, or database. Whether that boundary is secure depends on the surrounding identity, policy, network, and tool implementation.

Why Manufacturing Needs MCP

Integrating AI into the shop floor using legacy methods usually involves brittle custom API scripts or risky direct database connections. MCP solves three fundamental industrial pain points:

A Scoped Safety Boundary

AI models act as clients. They ask the MCP Server for specific data (e.g., "What is the current temperature of Oven 3?"). The MCP Server executes the query, fetches the data, and returns the result to the AI. Because the MCP Server handles the actual data extraction, you decide which operations exist at all: read tools for exploration, and any write tools limited, permissioned and logged. Direct machine control does not belong on the AI path.

Guardrails and Scoping (Governance)

With an MCP Server, you define the exact scope of what the AI is allowed to see. You can expose the last 7 days of OEE data and error logs, while keeping sensitive financial data or critical control tags outside exposed tool scopes. The AI doesn't get raw SQL access; it gets access to governed, pre-approved "Tools".

Auditability

The MCP service should record the authenticated principal, selected tool, parameters, result status, and relevant correlation data according to retention and privacy policy. Audit completeness depends on identity propagation and the surrounding application, not the protocol name alone.

How Proxus Secures AI with the Proxus MCP Server

Within the Proxus Industrial Data Platform, MCP is an optional governed consumer path for approved operational data. It does not replace dashboards, workflows, APIs, or established OT control interfaces. The same governed model also serves the AI Assistant built into the hub, which answers with the asking user's permissions and applies a change only after that user approves it; AI Assistant and agent access shows both paths.

The Proxus MCP Server runs inside your own deployment. It needs no AI service of its own: the AI client you connect brings its model, and you choose which client that is:

• Read tools by default, one write tool: the server exposes read tools plus a single write tool that can create or update records. Deletes are blocked by default.
• The user's own permissions: every call runs as the signed-in user, limited to that user's role and Unified Namespace path permissions. The AI client cannot see more than the person using it.
• Governed telemetry queries: historian queries are read-only, single statements against the telemetry store rather than arbitrary database execution. This narrows the surface but does not remove prompt-injection risk.
• Administrator controls: MCP can be switched off entirely, restricted to administrators, limited to read methods, and rate-limited.
• Full audit: every MCP request is logged with the user, the tool and the result.

The AI Assistant: the built-in assistant on the same governed data

MCP is for AI clients you bring yourself. Proxus also ships one: the AI Assistant, an assistant built into the hub, in Monitor > AI Assistant and as a side panel on every screen. It follows the same rules as the MCP path:

• The asking user's permissions: the AI Assistant reads with the permissions of the person who asks. A role limited to one site limits the assistant the same way, and passwords, keys, tokens and other secrets are never read.
• Proposals, not actions: a change appears as a card with each field before and after and what depends on the record. Nothing is written until the person who asked selects Approve and apply, and the change is then made with that person's permissions.
• The same audit trail: an approved change is recorded under the user's name, with the assistant and the conversation number as its source.

Unlike the MCP server, the AI Assistant needs a model to answer with. An administrator adds one or more AI services: Anthropic Claude, OpenAI, Azure OpenAI, Claude on Amazon Bedrock, Claude on Google Vertex AI, or a local model served by Ollama. With Ollama, nothing leaves the site; with Bedrock, Vertex AI or Azure OpenAI, the data stays in your own cloud account. Only data the asking user may read is sent. See The AI Assistant in Proxus and AI Assistant and agent access.

Real-World MCP Use Cases in the Factory

With a governed MCP implementation, teams can support workflows such as these while keeping the AI data path separate from machine control:

• Maintenance triage: A machine faults during an unattended shift. The technician asks an approved assistant to summarise recent alarms and compare them with governed error-code references. The result is a hypothesis for review, not a verified root cause.
• Shift handover drafting: A production manager asks the assistant to draft a handover report containing throughput, configured OEE exceptions, and outstanding maintenance work. A responsible user reviews the source data and draft before release.
• Energy review: An energy engineer asks the assistant to compare weekend energy consumption (kWh) with the production schedule and list high-draw machines that were left idling. The result is a list to check against the meter data, not a finding.

Conclusion

MCP can provide a consistent tool interface between approved AI clients and an industrial data platform. A governed middle layer such as the Proxus MCP Server (permission-scoped, logged, and limited to read methods if you choose) can reduce direct data-source exposure, but safety depends on the complete identity, authorization, audit, network, tool, and control-path design. AI remains a consumer of governed operational data, not the product category itself.

When this may not be suitable

• Lower-frequency telemetry may not justify full distributed complexity.
• Small single-line plants may prefer simpler architectures first.
• Strict legacy constraints may require phased adoption.
• Safety-critical closed-loop control should remain in PLC/Safety PLC layers.

Results vary with workload, hardware, and topology.

Frequently Asked Questions

What is MCP in simple terms?

MCP is an open protocol through which AI applications discover and invoke defined tools. A particular server may expose only read operations, but MCP itself is not inherently read-only or a complete security boundary.

Can MCP be used to control machines?

The protocol can represent tools with side effects, so the answer depends on the server. In industrial deployments, keep data exploration separate from machine-control authority. Any command path requires explicit authorization, validation, human or workflow approval where appropriate, audit, timeout, and safety design.

How does MCP differ from REST APIs for AI access?

REST defines resource-oriented HTTP interfaces, while MCP defines a protocol for AI-facing tools, resources, and prompts. MCP can standardize discovery and parameter schemas, but authentication, authorization, compatibility, and the mapping to Unified Namespace data still require implementation work.

References

1. Anthropic, "Model Context Protocol Specification" - The open standard defining server-client communication for AI tool use. modelcontextprotocol.io
2. IEC 62443 - Industrial cybersecurity standard relevant to securing AI access to OT systems.
3. NIST AI RMF (AI Risk Management Framework) - Framework for managing risks in AI deployments, applicable to industrial MCP implementations.