MCP server for business: connecting AI to company systems safely

An MCP server is a service that lets an AI assistant read selected company data and run precisely defined actions in your systems, such as a CRM, an ERP or an online shop. According to the official documentation, the Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems; it is supported by Claude, ChatGPT, Visual Studio Code and Cursor, among others (MCP documentation).

For a business, an MCP server makes sense when you want people to work with company data directly inside an AI assistant. If you only need to move data between two systems on a regular basis, you do not need MCP. One point matters from the start: security does not come from the protocol itself, but from which tools you expose, how you authenticate users and which actions a person has to confirm.

What an MCP server is and what it can expose

The MCP specification distinguishes three roles. The host is the AI application that initiates connections, the client is a connector inside that application and the server is a service that provides context and capabilities. They exchange messages in the JSON-RPC 2.0 format (MCP specification).

A server can offer three types of features:

Resources – context and data for the user or the AI model, for example a price list or an internal policy.
Prompts – prepared message templates and workflows for users, for example “summarize the customer’s status”.
Tools – functions executed by the AI model, for example looking up an order or creating a draft quote.

Tools deserve the most attention. According to the specification, the model can discover and invoke them on its own, based on the context and the user’s request (MCP: Tools). The specification also warns that tools represent arbitrary code execution, that the host must obtain explicit user consent before invoking them and that the protocol itself cannot enforce these principles (MCP specification).

When to use an MCP server, an API integration or a custom application

An MCP server does not replace every integration. Decide based on who starts the process and how precisely it has to run.

Situation	Suitable solution	Why
Employees want to search and work with data from several systems inside an AI assistant.	MCP server	One standardized layer can be used by different clients that support MCP.
Two systems need to exchange data regularly without human involvement, for example orders from the online shop to the ERP.	API integration	A fixed, repeatable data flow does not need a language model that makes its own decisions.
The process has fixed steps, approvals and clear responsibility, for example handling a complaint.	Custom application or controlled AI workflow	States, permissions and the audit trail stay under your control in your own interface.
You need a one-off analysis of a data export.	Export without a permanent connection	A server that has to be secured and maintained is not worth it for a one-off task.

According to the specification, MCP server tools can, for example, call APIs or query databases (MCP: Tools). For company systems, we recommend connecting through an API with dedicated, restricted permissions. If a system has no usable API, start there: a solid API integration is the foundation on which an MCP layer can be built later.

Security: what the specification requires and what you must add

Local or remote server

A local server that the client talks to over standard input and output (STDIO) should, according to the specification, retrieve its credentials from the environment. For servers available over HTTP, the specification defines authorization based on OAuth 2.1 (MCP: Authorization).

Practical recommendation: a local server with an API key on an employee’s laptop is fine for development or a personal test. For a team, a remote server is a better fit, because every user acts under their own identity and access can be revoked centrally.

Authorization and tokens

Authorization is formally optional in MCP, but treat it as mandatory for company data. A protected MCP server acts as a resource server under OAuth 2.1. Tokens are issued by an authorization server, which can run together with the MCP server or separately (MCP: Authorization).

Your project brief should include in particular these requirements from the specification:

the server must verify that the access token was issued specifically for it, and must not accept or pass on any other tokens,
it responds to an invalid or expired token with HTTP 401,
the token is sent in the Authorization header, never in URL parameters,
the client should request only the permissions (scopes) it really needs; when permissions are insufficient, the server should respond with HTTP 403 and the error insufficient_scope, and the client can request broader access.

It is also useful that the server may return the list of tools according to the caller’s permissions. A salesperson can therefore see different tools than the sales manager (MCP: Tools).

Tools, inputs and outputs

According to the specification, servers must validate all tool inputs, implement access control, rate limit tool calls and sanitize outputs. For clients, the specification recommends confirmation of sensitive operations, showing inputs before they are sent to the server, timeouts and logging of calls for audit purposes (MCP: Tools).

Human confirmation

According to the specification, there should always be a person who can deny a tool call. However, the protocol does not mandate a specific user interaction model, so what the confirmation looks like depends on the client (MCP: Tools). Design write actions so that they stay safe even after a hasty confirmation, for example as a draft that a person completes in the original system.

Example: a salesperson preparing for a meeting

Illustrative example, not a real client project. A distribution company uses a CRM and an ERP. Before a meeting, a salesperson wants to ask the AI assistant: “Prepare my notes for tomorrow’s meeting with customer ABC.”

In the pilot, the MCP server exposes four narrow tools:

find_customer – finds a customer, but only among the customers assigned to the signed-in salesperson,
list_recent_orders – returns orders from the last 12 months without internal notes on margins,
list_open_invoices – returns the amount, due date and status of invoices without bank details,
create_quote_draft – creates only a draft quote in the ERP, which a person then sends to the customer.

The first three tools are read-only. The fourth is visible only to users with permission to create quotes; before it runs, the salesperson must confirm the displayed inputs in the client, and the server logs who used the tool, when and with which parameters. If the AI assistant misunderstands the request, the worst outcome is an incorrect draft, not a quote that has already been sent.

Implementation in seven steps

The steps assume that the system has an API or another interface that can be connected securely.

Pick one task. For example, meeting preparation or checking an order status. A brief like “connect AI to everything” cannot be tested.
List the data and actions. For each data item, decide whether the AI may read it, and for each action, whether it may run it. Return personal and sensitive data only when the task really requires it.
Design narrow tools. No universal tool such as “run SQL” or “call any API”. Every tool has a precise input schema, limits and, for structured results, an output schema that the server’s response must conform to (MCP: Tools).
Set up authorization. A remote server with user identity, role-based permissions and a check that the token belongs to this very server. For calls to the CRM or ERP, give the server its own separate, restricted credentials.
Add operational safeguards. Input validation, rate limits, timeouts, output sanitization and an audit log.
Configure confirmations. Write tools require confirmation and, in the pilot, must not delete anything or send anything outside the company.
Run a pilot with a small group. Decide in advance how long it will last and how you will evaluate it. Monitor logs, errors and questions the tools could not handle, and only then add more tools or users.

Trade-offs to accept consciously

Flexibility at the cost of predictability. The model decides on its own which tool to call. That is an advantage for questions you cannot anticipate. For processes that must always run the same way, it is a disadvantage, and a controlled workflow belongs there instead.

One integration, different clients. The MCP documentation states that, thanks to broad support, an integration can be built once and used in different applications (MCP documentation). How a particular client displays tools and confirmations, however, has to be checked for each client you want to allow.

The protocol evolves. MCP versions are labeled with the date of the last backwards incompatible change; at the time of writing, the current version is 2026-07-28. Deprecated features remain in the specification for at least 12 months, or at least 90 days under expedited removal (MCP: Versioning). Plan for regular maintenance of the server.

Data goes to the AI model. Tool results are processed by the model the client uses. Before launch, check the data processing terms of the client’s provider and return only the data the task really needs.

Common mistakes

A universal tool with an administrator key that lets the model do almost anything.
One shared service account for everyone, so there are neither personal permissions nor an audit trail.
Accepting any token from the company sign-in without checking whether it was issued for this server.
Tokens in URLs or in logs.
Automatic approval of write tools without human review.
Full records with personal data where a summary would do.
Connecting a third-party MCP server without vetting it. Descriptions of tool behavior from untrusted servers should be treated as untrusted (MCP specification).

Pre-launch checklist

Before you make the server available to its first users, you should be able to answer yes to every point:

We have one specific task and know how we will evaluate the pilot.
Every tool has an owner, a description, an input schema and limits.
Reading and writing are in separate tools; deleting and sending outside the company are not part of the pilot.
The server verifies the user’s identity and that the token was issued for it.
The list of tools and the returned data match the user’s role.
Write tools require confirmation and only create drafts.
Calls are logged, have a timeout and are rate limited.
We can quickly revoke access for an individual user as well as for an entire client.
We know the data processing terms of the AI client’s provider.
We know who updates the server when a new protocol version is released.

Frequently asked questions

Do we need an MCP server if we already have an API?

Only if you want to work with the data from an AI assistant. The API remains the foundation, and the MCP server adds on top of it a layer of tools with descriptions, schemas and permissions that an AI client can work with. If you do not need an AI assistant, the API on its own is enough.

Can the AI delete or send something through an MCP server without our knowledge?

Only if you expose such a tool and the client allows it to run. The specification recommends that a person should always be able to deny a tool call. The safest approach is not to offer tools for deleting or sending in the pilot at all.

Is a local or a remote MCP server better?

A local server suits development and personal use, because it takes its credentials from the computer’s environment. For a team, a remote server with OAuth 2.1 authorization, personal permissions and the ability to revoke access centrally is a better fit.

Will an MCP server work with any AI assistant?

Only with clients that support MCP; the documentation lists, for example, Claude, ChatGPT, Visual Studio Code and Cursor. The protocol does not mandate how tools and confirmations are displayed, so the chosen client should be part of the pilot.

Next step

If you are considering making your CRM, ERP or online shop available to AI assistants, start with one task and a few read-only tools. Webiant can help you design the tools, authorization and pilot as part of custom AI agent development. Get in touch through our contact page and describe the system and the task you want to simplify. You will find more practical guides on the Webiant blog.

Sources

What is the Model Context Protocol (MCP)? – introduction in the official MCP documentation
Specification (2026-07-28) – roles, server features and security principles
Tools – tools, human oversight and security requirements
Authorization – authorization of MCP servers available over HTTP
Versioning – version labeling and feature lifecycle