MCP (Model Context Protocol) is an open standard for connecting AI assistants and agents to external systems: databases, business applications, documents and tools. It works as a common connector. Your company builds one MCP server for its system, and any compatible AI application can query it and act on it, within the permissions you define. For a business, MCP is the most direct way to let AI work with real data without building a separate integration for every tool.

What MCP is and where it comes from

Anthropic introduced MCP on 25 November 2024 as “a new standard for connecting AI assistants to the systems where data lives”. The official documentation compares it to a USB-C port for AI applications: one standard connection instead of a different cable for every device.

MCP no longer depends on a single company. On 9 December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. Anthropic, Block and OpenAI co-founded it, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. The announcement states that MCP’s governance model stays the same: maintainers keep making decisions in the open, with community input.

This matters when you choose a technology. A standard with neutral governance lowers the risk of being locked into one AI vendor.

How MCP works: the architecture

The MCP specification (current revision: 2026-07-28) defines three roles. Messages use the JSON-RPC 2.0 format.

Role	What it is	Example
Host	The AI application the person uses	A desktop assistant, an IDE or your own chatbot
Client	The connector inside the host that talks to one server	The assistant module that connects to your CRM
Server	The service that exposes a system’s data and actions	The MCP server for your ERP, CRM or document store

What an MCP server offers

An MCP server can offer three kinds of capabilities:

Tools: functions the AI model can execute, such as find_customer, create_task or get_invoice.
Resources: data and context for the person or the model, such as a document, a record or a list.
Prompts: message templates and workflows the person picks, such as “prepare this customer’s weekly summary”.

Clients can also offer features to servers. The main one is elicitation: the server asks the person for missing information, for example to confirm an amount.

Transports: local and remote

The specification defines two standard transports:

stdio: the host launches the server as a local process, and they talk over standard input and output. This is common for tools on the user’s own machine.
Streamable HTTP: each message is an HTTP POST to a single server endpoint. The reply comes back as JSON or as an SSE stream. This is the transport for remote servers, which is the normal setup for a company system.

The 2026-07-28 revision makes the protocol stateless at the transport level: every request carries its protocol version and capabilities. Earlier revisions used a session with an initial handshake, and compatible clients and servers detect which version the other side speaks.

MCP vs a REST API vs plugins

MCP does not replace your API. In most cases, the MCP server calls your API or service layer underneath. The difference is who consumes it and how.

	Classic REST API	Plugin for one AI tool	MCP server
Who consumes it	Programs written by developers	A single AI application	Any MCP-compatible AI application
Discovery	Documentation a person reads	Each vendor’s own format	The client asks the server for its tools, with descriptions and parameters
Design	Technical resources and operations	Depends on the vendor	Tools designed for a model to understand and use
Reuse	High, but each AI integration is a new project	Low: one plugin per vendor	High: one server works with many hosts
Authorisation	Whatever the API defines	Whatever the vendor defines	OAuth 2.1 for HTTP transports, per the specification
Best fit	System-to-system integrations without AI	One assistant, no plans to change	Several assistants or agents using the same system

The rule of thumb: if two systems talk to each other without AI, use an API or a classic integration. We cover that in systems integration for ERP and CRM. If you want an AI assistant or agent to work with the system, MCP saves you from repeating the integration for each tool.

MCP use cases in business

MCP adds value when a person wants to ask something in plain language and the answer depends on internal data:

Query and operate the CRM or ERP. “Which invoices does this customer have outstanding?”, “create a follow-up task for Monday”. The assistant calls the server’s tools with the permissions of the user who asks.
Internal knowledge. An MCP server exposes search over company documentation (procedures, contracts, manuals). Underneath there is usually a RAG system, which we explain in what RAG is and how to use it with company documents.
Ticketing and support. The assistant reads the ticket, checks the customer’s history, suggests a classification and creates or updates the ticket.

When the AI has to decide several steps in a row, we are talking about an agent. We cover agents in depth in AI agents for business. MCP is the piece that connects that agent to your systems.

The MCP server for our CRM

At LCApps we have built an MCP server for our own CRM. It lets an AI assistant query and operate on customers, tasks, invoices and expenses, always with the permissions of the user who is using it. If a person cannot see or change an invoice in the CRM, the assistant cannot do it on their behalf either.

The main lesson: the hard work is tool design, not the protocol. You decide what the assistant can do, which data it sees and which actions need confirmation. We design and operate these projects in compliance with the GDPR and the EU AI Act.

Security: authorisation, permissions and risks

An MCP server gives an AI access to real data and real actions. Security is the most important part of the project.

Authorisation in the specification

The authorisation specification is optional, but for HTTP transports it is based on OAuth 2.1. The key points:

The MCP server acts as an OAuth 2.1 resource server and publishes its metadata under RFC 9728, so the client can find the authorisation server.
The client uses PKCE and states which server the token is for (resource indicators, RFC 8707).
The server must validate that each token was issued for it. It must not accept or forward tokens issued for other services. The specification forbids this “token passthrough”.
With the stdio transport, the specification says credentials come from the environment, not from this flow.

In practice, this lets users sign in with your identity provider, so the assistant acts with their permissions, not those of a technical account with full access.

Least privilege

The MCP security best practices recommend a progressive permission model: start with low-risk read scopes and request more only when an operation needs them. Avoid wildcard scopes such as admin or *.

Apply the same idea to tool design:

Keep read tools separate from write tools.
Do not expose operations nobody needs, such as bulk-deleting customers.
Enforce the same business and permission rules in the server as in the application. Never rely on the model “behaving”.

Human confirmation for write actions

The specification says the host must obtain the user’s explicit consent before invoking a tool, and that users should understand what each tool does. For a business the recommendation is simple: actions with impact (issuing an invoice, sending something to a customer, changing a status) need a person to confirm them.

Prompt injection

An email, document or ticket can contain text that tries to give the model orders. OWASP calls this indirect prompt injection: the model receives instructions from an external source such as a file or a website. The MCP specification itself says tool descriptions should be treated as untrusted unless they come from a trusted server.

Connect only MCP servers from known sources, require confirmation for write actions and limit in the server what each tool can do.

Audit log

Log every tool call: who, when, which parameters and what result. Without that log you cannot investigate an error or show what the assistant did.

An MCP server that exposes customer or employee data is processing personal data. Keep the GDPR in mind:

Data minimisation (Article 5). Each tool should return only the data its task needs.
Processors (Article 28). The AI model that reads the responses is usually run by an external provider. You need a data processing agreement and you need to know where the data is processed.
Automated decisions (Article 22). If the assistant takes part in decisions with significant effects on people, keep a human in the loop.
Impact assessment (Article 35). If the processing is likely to create a high risk for people, carry out a DPIA before going live.

EU AI Act

MCP is a connection protocol. Regulation (EU) 2024/1689 does not regulate it as such, but it does regulate the AI system that uses it. The Article 50 transparency obligations apply from 2 August 2026: if the assistant talks to people outside the company, they must know they are dealing with an AI. If the use case is high-risk, such as recruitment or employee evaluation, the obligations are much heavier. We summarise them in EU AI Act obligations for businesses.

How to build an MCP server for your system

Building an MCP server is a custom software development project like any other integration. These are the steps we follow:

Pick the use cases. Start with 3 to 5 questions or actions the team performs every day. Do not expose the whole system at once.
Design the tools. Each tool needs a clear name, a description the model understands and typed, validated parameters. A narrow tool works better than a generic one.
Define permissions and confirmations. Decide which tools are read-only, which write, and which need human confirmation.
Connect through your service layer. The MCP server must apply the same business rules as the application. Do not go straight to the database.
Implement authorisation. For a remote server, use OAuth 2.1 with your identity provider and validate the audience of every token.
Use an official SDK. There are official SDKs for TypeScript, Python, C#, Go, Rust, Ruby, Java, Swift, PHP and Kotlin.
Log and monitor. Record every call and track errors, latency and usage per tool.
Test with real users. Run a pilot with a small group, review the conversations and refine the tool descriptions.

Cost depends on the number of tools and the current state of your system. We explain the drivers in how much custom software development costs.

Frequently asked questions

Is MCP only for Claude?

No. Anthropic created it, but the Agentic AI Foundation, under the Linux Foundation, now hosts it. According to the official documentation, assistants such as ChatGPT and developer tools such as Visual Studio Code and Cursor support it too.

Do I need MCP if I already have an API?

Not if you only want to connect two systems without AI. If you want one or more AI assistants to use your system, MCP saves you from building an integration for each one. The MCP server usually calls your API underneath.

Can the assistant see all the data in my system?

Only what the tools expose and the user’s permissions allow. A well-built MCP server applies the same access rules as your application.

Is my data used to train the model?

MCP does not decide that. It depends on the model provider and your contract. Check the terms of the enterprise plan or API before connecting customer data.

Conclusion

MCP is the standard way to connect AI assistants and agents to a company’s systems. The protocol handles the connection; the value and the risk sit in tool design, permissions and oversight.

At LCApps we build MCP servers, agents and chatbots connected to the systems you already use, in compliance with the GDPR and the EU AI Act. Tell us which process you want to improve and we will help you design a realistic first MCP server.