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

The problem: Claude is smart but isolated

Out of the box, Claude 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, look up a customer's order history, or check your pricing spreadsheet. It's like hiring a brilliant new employee and then not giving them access to any of your systems.

You can copy-paste data into a conversation, 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 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. Think of it as a universal adapter between Claude and any data source your business uses.

Here's the simplest way to understand it: 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, so Claude can ask questions like “what's the current price for a C-Series 600 press?” and get a real answer from your real system.

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

How it works: the three layers

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. It defines what Claude can read (queries, lookups, searches) and what it can write (create records, update fields, trigger actions). This is what you build.
• Claude— the AI layer that your team interacts with. Claude calls the MCP server when it needs data, and the server returns structured results. Your team never sees the MCP layer — they just talk to Claude and get accurate, live answers.

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

What this looks like in practice

We recently deployed AI across seven departments of a manufacturing company. One of the biggest blockers was their custom-built ERP — not SAP, not Odoo, not Tally. A bespoke system built over decades, holding everything from inventory levels to purchase orders to production schedules.

Without an MCP connector, 14 of their 49 identified use cases were blocked. Claude could generate offers, but not pull live pricing. It could draft purchase orders, but not assign PO numbers from the system. It could analyse financial data, but only from manually exported spreadsheets.

The MCP connector we built gave Claude the ability to:

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

Each of these is a “tool” defined in the MCP server. Claude knows these tools exist, knows what inputs they need, and knows what outputs they return. When a procurement manager asks Claude to “create a purchase order for 500 units of component X,” Claude calls the right MCP tool, gets the next PO number, pulls the current price, and assembles the document — all from live data.

What you can connect

MCP works with anything that has a programmable interface. In practice, that means:

• ERP systems— SAP, Odoo, Tally, or custom-built. If it has an API or database, it can be connected.
• CRM platforms— Salesforce, HubSpot, Zoho. Claude can read customer data, update deal stages, create follow-up tasks.
• Databases— PostgreSQL, MySQL, MongoDB. Claude can query and write to your database directly (with appropriate read/write permissions).
• Spreadsheets and file systems— Google Sheets, shared drives, document repositories. Claude can read the latest data without manual uploads.
• Communication tools— Slack, email, messaging platforms. Claude 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 can use it.

The anatomy of an MCP server

An MCP server is surprisingly simple. It defines three things:

• Tools— the actions Claude can take. Each tool has a name (like “get_inventory_level”), a description (so Claude knows when to use it), inputs (what parameters it needs), and outputs (what it returns).
• Resources— read-only data that Claude can access. Think of these as reference material — product catalogues, pricing tables, policy documents — that Claude can look up but not modify.
• Permissions— guardrails on what Claude 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 asking Claude 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. It's a 2–4 week development project, not a months-long enterprise integration.

Why this matters for your business

Most AI deployments stall because the AI can't access the data it needs. People try Claude, get generic results because it's working without context, and conclude that AI isn't ready for their workflows.

MCP changes that equation. When Claude 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 we referenced earlier, MCP unlocked 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.

Getting started

You don't need to connect everything at once. The practical approach:

• Start with read-only— connect Claude 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 to act autonomously within defined boundaries.

Each step builds trust in the system. By the time you're automating, your team has been using AI-assisted workflows for months and understands exactly what it can and can't do.

The bottom line

MCP is the infrastructure layer that turns Claude from 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 an MCP server. The question isn't whether it's technically possible — it's whether you have the deployment structure to make it useful. That's the part most companies skip.