MCP (Model Context Protocol) is an open standard that gives AI a uniform way to connect to your ERP, website admin, databases and cloud drives. Once a system has an MCP interface, you can say "List this week's orders that haven't shipped" in the chat and the AI looks it up itself. Whether that's safe depends on how the interface is built: permissions follow the signed-in person, a person confirms before data changes, and every call is logged.

If you've used Claude or ChatGPT, you may already export a spreadsheet from the ERP and paste it in for a summary. That's simple, it works and it's a good place to start. This article begins with two prompts for today, then a checklist, how MCP works and how to connect safely.

Ask AI first

You can start preparing with an AI assistant such as ChatGPT, Claude or Gemini before you have MCP. Swap in your own details (the examples are illustrative).

Map which tasks AI should connect to

Our company uses an ERP (orders, inventory, receivables), a website admin, accounting software and a shared cloud drive. Below are the 10 tasks each department does most often, such as checking whether an order has shipped, answering customers about stock and compiling weekly sales. Make a table: which system each task uses, whether AI only needs to read or also to change data, and if so which data. Then, based on how often each happens and the impact of a mistake, pick the 3 to connect to AI first.

Try your future questions on an exported report

Attached is an order report exported from our ERP (order number, customer code, payment status, shipping status, promised date). In a table, list the orders that are paid but not yet shipped. Then sum up: if you could look things up in the system directly later, which lookups would you need (for example, "find orders by payment status"), and what would each take as input and return?

Treat the AI's lists as a draft. Have each department check them against a real week: what do people actually sign in to systems for, and which items come up most? The questions it answers accurately become your MCP tool list later. Before uploading, use your company's enterprise plan, or replace customer names with codes and delete unneeded columns.

3 things you can do now

None of this needs any code, and whether or not you use MCP later, it makes your systems and permissions clearer.

1. Ask your system vendors these questions

  • Is there an API? Can the system export to Excel or CSV?
  • Can you set up read-only accounts or role-based permissions?
  • Does it keep an activity log?
  • Does it offer an MCP interface, or is one planned?

Systems with an API get MCP running much faster.

2. Make sure everyone has their own account and role

MCP uses the signed-in person's permissions, so first check that every colleague has their own account and that roles match how work is actually divided: sales reps see their own customers, and accounting sees receivables.

3. Decide what data the AI can see

Sort the fields you use most into three groups: AI can see it, summary only and never (national ID numbers or bank account numbers, for example). At the same time, check the terms of the AI service plan your company uses: is data stored, and is it used for training?

What problem does MCP solve?

Before MCP, every AI tool needed its own integration code for every system. Say your company has 5 systems and the team uses 3 AI tools: in theory that's 15 separate integrations, and an update on either side means changing them.

MCP works a lot like USB: build one MCP interface for a system, and every AI that supports MCP can plug in. What used to be "systems × AI tools" becomes "systems + AI tools."

Without MCP, every AI tool needs its own integration with every system and the lines cross; with MCP, everything connects through one shared interface
Left: each AI tool integrates with each system separately, so the number of integrations multiplies. Right: each system builds one MCP interface that every AI shares.

How does MCP work?

MCP has three roles:

  • Host: the AI application you're using, such as the Claude desktop app, ChatGPT or your company's in-house AI assistant.
  • Client: the part of the host that talks to the server.
  • Server: an interface layer wrapped around the system that describes what it can do in a format AI understands.

An MCP server mainly offers three things:

  1. Tools: actions the AI can call, such as "look up orders" or "send notification." Each tool comes with a description and a parameter format, so the AI knows when and how to use it.
  2. Resources: data the AI can read, such as a product catalog or an operations manual.
  3. Prompts: ready-made task templates, such as "generate this week's operations report."

When you ask for something in the chat, the AI uses the tool descriptions to decide which tool to call. The server runs it and returns the result, and the AI turns that into an answer or decides on the next step. This is the foundation that lets AI agents "do things on their own."

How is MCP different from a regular API?

In short: APIs are for engineers; MCP is for AI.

Regular APIMCP
Who uses itEngineers write code that calls itThe AI decides to call it based on the conversation
IntegrationEach application integrates separatelyAny AI that supports MCP can connect directly
Best forSystem-to-system integration with fixed flowsWork that requires understanding the request and flexibly combining several actions

MCP doesn't replace APIs. An MCP server is usually built on top of existing APIs: it wraps the API as tools AI can understand, then adds permission checks and confirmation steps.

Permissions and security: four things to check

MCP's design includes several security mechanisms, but real security depends on how the server is built. When you evaluate any MCP setup, check these four points:

OAuth authorization instead of shared passwords

Remote MCP servers use OAuth for authorization. The first time a user connects, they confirm on a consent screen which scopes they're granting (read-only, for example, or also permission to make changes). What the AI receives is a time-limited, revocable pass, not a username and password.

The AI only gets "this person's" permissions

A well-built MCP server ties permissions to whoever is signed in: sales reps see only their own customers, and only accounting can see receivables.

Write actions need a person's confirmation

Lookups can run right away. Creating, changing or deleting records, sending email and issuing refunds are designed as two steps: the AI first proposes "here's what I'll do," and it only runs after the user has reviewed and confirmed it.

The MCP permission flow: the user signs in and authorizes, the AI calls a tool, the server checks permissions, write actions require confirmation, and every operation is logged
A safe MCP call: OAuth authorization → permission check → confirmation before any write → an audit log.

Every call is logged

Who, when, through which AI, which tool and with what result: all of it is recorded, so you can trace problems and use the logs to fine-tune permissions.

When to consider the next step

It's worth building an MCP interface for your systems when:

  • "Sign in, look up, export, paste into the AI" happens several times a day, and more often over time.
  • Managers would like to check orders, inventory or website status in one sentence, without waiting for a report.
  • You want one weekly report that covers orders, accounting and website traffic together.

The next step: build an MCP layer for your systems

The approach is to wrap an MCP server around your system, without replacing the system you already have. We suggest going in phases:

  1. Start with lookups: turn the lookups you listed and checked with your team into read-only tools.
  2. Design tools instead of opening up the whole database: one tool per job, with separate permissions; descriptions written for the AI; only the fields that are needed in the results; and clear error messages (such as "Customer not found. Please check the customer code") so the AI can correct itself.
  3. Build permissions and confirmation into the server: don't count on the AI to "follow the rules" on its own. Every write action is proposed first and confirmed by a person.
  4. Pilot with a few people and adjust based on the logs: the call logs show which tools get used most and where they're easy to misuse, so you can open things up step by step.

Uses we've built ourselves or that clients ask about most: asking AI in Claude to update the website admin (it asks you to confirm before changing anything), looking up orders that are paid but not yet shipped, summarizing the questions customers ask most, and producing a cross-system weekly report.

Xena, the AI assistant from StudioX, is built the same way: it always asks a person before changing data, every step is logged, and it can be set to read-only. The first phase usually goes live in about 4–6 weeks, while your current way of working carries on. If a system doesn't have an API yet, you can wrap an integration layer around it first (see connecting older systems without replacing them).

To find out how your systems could connect to AI, start with a free AI Health Check, or take a look at our integration services and AI services. You're also welcome to get in touch.