How AI Talks to Your ERP: The Model Context Protocol

Imagine to be part of an integration team that just spent three months and €50,000 building custom APIs so an AI agent could read inventory and track orders. The next day, the system vendor updated their schema, and the entire stack crashes.

Integrating AI with enterprise systems is turning into a nightmare of custom development and fragile connections.

This is the third episode of Pragmatic AI for Operations, a series designed to bring architectural discipline to generative AI projects on the production floor.

Custom Integration Trap

The biggest bottleneck of generative AI in operations lies at the integration layer level.

When a company decides to deploy an autonomous agent to assist with inventory reconciliation, the IT department is hit with a list of custom requirements. The agent needs to check active stock in the WMS, read the latest pricing in the ERP, scan PDF contract clauses in a shared drive, and query other portals.

Traditionally, this meant writing custom integration scripts, configuring API gateways, and managing separate authentication flows for every single tool.

This approach can be risky some times. Why? Well, If the vendor updates their software, the custom connector needs to be re-aligned.

If your database schema changes, the queries fail. If you decide to swap the underlying language model for a cheaper or faster alternative, you must rebuild the entire bridge.

You end up with a brittle web of custom endpoints that are expensive to build and nearly impossible to maintain.

It is the modern equivalent of spaghetti code, gift-wrapped in AI hype.

The USB-C Port for AI

To solve this integration issue, a standard interface is needed. A better way to connect reasoning engines to data sources without building a bespoke bridge every time.

This is why Anthropic open-sourced the Model Context Protocol (MCP).

Think of MCP as the USB-C port for AI. Before USB-C, every device required a proprietary charger and a unique port. Now, a single cable handles power, video, and data across different manufacturers.

MCP does the same for generative AI. It is an open, standardized protocol that defines how a client (the application hosting the AI model) communicates with server applications that expose data and tools.

Instead of writing custom API code for every tool, you build or deploy standard MCP servers.

Once an MCP server is running, any compatible AI model can query its data, read its files, or trigger its actions. The model does not need to learn the specific language of your database or the structure of your internal directories.

It speaks MCP.

Host, Client, and Server: The Three-Tier Architecture

The protocol divides the integration work into three distinct components.

The Host is the primary application running the AI agent. A development framework, a local orchestration tool, or your internal software dashboard. It manages the workflow and controls what the agent is allowed to do.

Inside the Host sits the Client, the component that initiates and maintains the connection. It translates the language model’s requests into standardized MCP commands.

Then there is the Server, a lightweight program that runs close to the target system. An MCP server connects to a specific data source, like a Postgres database, a local folder of text files, or a shipping API. It translates the raw data of that system into the standard format defined by the protocol.

This separation of concerns is clean.

The language model remains isolated from the underlying database credentials and network details. The model only interacts with the Client. The Client handles the communication with the Server.

And the Server handles the query execution.

Two Integrations: The Delayed Steel Shipment

To understand the difference this makes, let us look at a practical scenario on the loading dock.

A logistics coordinator is dealing with an urgent shipment of raw steel sheets that has not arrived. They delegate a goal to an autonomous agent: Find the status of the steel shipment, and locate our standard operating procedure for carrier delays.

To resolve this request, the agent must execute three tasks:

1. Query the ERP database to check the open purchase order details.
2. Search a carrier tracking website to get the real-time location of the truck.
3. Read a local folder containing PDF documents to find the supplier compliance policy.

The Traditional Way

Without a standardized protocol, your IT team must build three separate integrations.

They write a custom script to connect the model to the SQL database, handling query formats and credentials. They write a web scraper to fetch carrier updates. They set up a document parser to extract text from the PDF files and load it into a vector database.

This requires three different development projects, three sets of credentials stored inside the application code, and weeks of testing.

If the carrier changes their website layout, the scraper breaks. If the database schema is updated, the SQL script fails.

The MCP Way

With the new protocol, you deploy three standard MCP servers:

1. A database MCP server that connects to your **ERP data.
2. A search MCP server that queries the web.
3. A filesystem MCP server that monitors the folder of PDF manuals.

Your host application connects to these three servers through the unified protocol. The AI agent immediately sees the database tables, the web search utility, and the local files as standard resources and tools.

The agent queries the database, checks the tracking link, and reads the compliance document using the exact same interface.

The integration effort drops from weeks of custom programming to a few lines of configuration code.

Securing the Gateway

In an industrial environment, giving a probabilistic model direct access to your core systems is never a smart move. If an agent has raw SQL write access to your ERP, it could delete transactions or modify purchase orders during a reasoning loop.

MCP provides security by design through strict boundaries.

First, the protocol is local-first. The MCP servers run inside your private network, behind your corporate firewall. The language model, even if it is a cloud API, never establishes a direct network connection to your database. It only communicates with the host application, which forwards standard requests to the local servers.

Second, the servers enforce strict resource boundaries. You don’t give the agent raw access to the database. Instead, the database MCP server can be configured to expose only read-only views of specific tables, or only accept pre-defined query templates. The agent cannot execute arbitrary SQL commands because the server simply will not process them.

Third, the protocol creates a complete audit trail.

Every query, resource read, and tool execution passes through the standard MCP interface. The host application can log every single command sent to the servers.

If an agent behaves unexpectedly, you don’t have to dig through unstructured logs. You can audit the exact JSON payloads exchanged between the client and the servers to see what data the model requested and what actions it took.

Protecting the Core

The real value of the Model Context Protocol is that it supports the decoupled architecture we explored in our previous episode.

By standardizing the connection layer, we keep the intelligence at the edge and the stability at the core. The ERP remains deterministic, running standard database rules and validation checks. The AI agent operates at the edge, querying data through clean, read-only MCP servers and preparing solutions for human approval.

We eliminate an integration debt that can kill tons of generative AI projects.

If a better language model is released, you can swap it into your host application without changing a single line of your database connectors. Your data access layer remains stable. Your integration investment is preserved.

In our next episode, we will dive deeper into the retrieval layer: Vector RAG vs. Structured Knowledge Graphs, and explain how to choose the right retrieval strategy for the right operational data.

Written by Andrea Guaccio 

July 9, 2026