MCP Explained: How to Connect Your ERP, CRM, and Internal Systems to Claude AI

The problem: Claude AI is smart but isolated

Last Tuesday, a procurement manager at one of our client sites asked Claude AI to generate a purchase order. Claude AI wrote a beautiful PO. Perfect formatting, professional language, all the right fields. One problem: every single number in it was made up.

That's the core issue. Out of the box, Claude AI can write, analyse, summarise, and reason, but it can't see your data. It doesn't know what's in your ERP. It can't pull your latest inventory levels or look up a customer's order history. It's like hiring a brilliant new employee and then locking them out of every system on their first day.

You can copy-paste data into a conversation, sure. But that doesn't scale. You can upload files, but those go stale the moment the source data changes. What you actually need is a live connection, a way for Claude AI to reach into your systems, read what it needs, and write back when appropriate.

That's what MCP does.

What MCP is, in plain English

MCP stands for Model Context Protocol. I know, the name sounds intimidating. It's not. Think of it as a universal adapter between Claude AI and any data source your business uses.

Your ERP, CRM, database, or spreadsheet has data. That data lives behind some kind of access layer (an API, a database connection, a file system). MCP is a standardised wrapper that translates between that access layer and Claude AI. So when Claude AI needs to answer “what's the current price for a C-Series 600 press?” it actually pulls the real number from your real system.

Without MCP, Claude AI is guessing or relying on whatever you paste in. With MCP, it's working with live data.

Three layers, that's it

Every MCP integration has three parts:

• Your system, the ERP, CRM, database, spreadsheet, or internal tool that holds the data. This is what you already have.
• The MCP server, a small piece of software that sits between your system and Claude AI. It defines what Claude AI can read (queries, lookups, searches) and what it can write (create records, update fields, trigger actions). This is the piece you build.
• Claude AI, the AI layer your team interacts with. Claude AI calls the MCP server when it needs data, and the server returns structured results. Your team never sees any of this plumbing. They just talk to Claude AI and get accurate, live answers.

The MCP server is the key piece. It's essentially a contract: here are the things Claude AI is allowed to do with this system, here's the data format for each action, and here are the guardrails.

A real example from a factory floor

I want to tell you about a deployment that almost didn't work.

We were rolling out AI across seven departments of a manufacturing company. Everything was going well until we hit their ERP. Not SAP, not Odoo, not Tally. A custom-built system, assembled over decades, holding everything from inventory levels to purchase orders to production schedules. Nobody outside the company had ever connected anything to it.

I honestly wasn't sure we could make it work. Their documentation was sparse. The API was partially undocumented. But without connecting to this system, 14 of their 49 identified use cases were completely blocked. Claude AI could generate offers but not pull live pricing. It could draft purchase orders but not assign PO numbers. It could analyse financial data, but only from manually exported spreadsheets.

So we built the connector. And it unlocked everything.

Claude AI could now:

• Read inventory levels, checking current stock of any component in real time
• Look up pricing, pulling the correct price for any product configuration, including head count calculations and margin rules
• Generate PO numbers, creating sequential purchase order numbers that match the ERP's numbering system
• Query order history, looking up past orders by customer, product, or date range
• Trigger reorder alerts, flagging when component inventory drops below minimum thresholds

Each of these is a “tool” defined in the MCP server. When a procurement manager asks Claude AI to “create a purchase order for 500 units of component X,” Claude AI calls the right tool, gets the next PO number, pulls the current price, and assembles the document. All from live data. No more made-up numbers.

So what can you connect?

Basically anything with a programmable interface. In practice:

• ERP systems like SAP, Odoo, Tally, or custom-built. If it has an API or database, it can be connected.
• CRM platforms like Salesforce, HubSpot, Zoho. Claude AI can read customer data, update deal stages, create follow-up tasks.
• Databases like PostgreSQL, MySQL, MongoDB. Claude AI can query and write to your database directly (with appropriate read/write permissions).
• Spreadsheets and file systems like Google Sheets, shared drives, document repositories. Claude AI can read the latest data without anyone manually uploading anything.
• Communication tools like Slack, email, messaging platforms. Claude AI can send notifications, draft messages, or respond to queries in-channel.
• Industry-specific tools, accounting software, project management systems, ticketing platforms, booking engines. If it has an API, Claude AI can use it.

Inside an MCP server

Here's what surprised me when I first started building these: an MCP server is actually simple. It defines three things:

• Tools, the actions Claude AI can take. Each tool has a name (like “get_inventory_level”), a description so Claude AI knows when to use it, the inputs it needs, and the outputs it returns.
• Resources, read-only data that Claude AI can access. Think product catalogues, pricing tables, policy documents. Claude AI can look these up but not modify them.
• Permissions, guardrails on what Claude AI can and cannot do. Read-only access to financial data. Write access to create draft purchase orders but not approve them. No access to salary information. These rules are enforced at the MCP layer, not by politely asking Claude AI to behave.

A typical MCP server for a mid-size manufacturer might have 10–20 tools, a handful of resources, and clear permission boundaries for different user roles. We're talking a 2–4 week development project, not a months-long enterprise integration.

Why should you care?

Have you noticed how many AI pilots quietly die? I see it constantly. A team tries Claude AI, gets generic results because it's working without any context about their business, and concludes that AI isn't ready for their workflows.

That's the wrong conclusion. The AI was ready. It just couldn't see anything.

MCP changes that equation. When Claude AI can read your pricing rules, query your inventory, and pull from your knowledge base, it stops being a generic assistant and starts being a workflow participant. The output goes from “here's a template you can fill in” to “here's the completed document with the correct data.”

In the manufacturing deployment I mentioned earlier, MCP was the difference between Tier 1 use cases (instructions and knowledge files only) and Tier 3 use cases (live system integration). Tier 1 saved time. Tier 3 eliminated entire manual processes.

Where to begin

You don't need to connect everything at once. That would be overwhelming, and honestly, you'd learn the wrong lessons from it. Here's the path I recommend:

• Start with read-only. Connect Claude AI to your most-referenced data sources (pricing, product specs, customer history) with read-only access. No risk, immediate value.
• Add write actions carefully.Once you're confident in the output quality, add the ability to create drafts (purchase orders, invoices, reports) that require human approval before finalising.
• Automate with guardrails. For high-confidence, repetitive actions (reorder alerts, status updates, notification triggers), allow Claude AI to act autonomously within defined boundaries.

Each step builds trust. By the time you reach automation, your team has been using AI-assisted workflows for months and understands exactly what it can and can't do. There are no surprises.

The bottom line

MCP is what turns Claude AIfrom a smart chat interface into a real business tool. It's not a product you buy. It's a connector you build, specific to your systems, your data, and your workflows.

Every business that uses a CRM, ERP, database, or internal tool can build one. The real question isn't whether it's technically possible. It's whether you have the deployment structure to make it useful. And that, in my experience, is the part most companies skip.