Your team already uses an AI assistant such as Claude, ChatGPT or Microsoft Copilot. Sooner or later someone asks the obvious question: why can it not look up an order, check stock, or read a customer record in our own system? The Model Context Protocol (MCP) is the open standard designed to answer that question. This article explains what MCP is, how it works, which products support it, what it takes to connect your own system, and where the risks are, so you can decide whether it deserves budget now or a note in next year's plan.

Quick answer

The Model Context Protocol is an open standard for connecting AI applications to external systems. The official documentation describes it as "a USB-C port for AI applications": you build one connector (an MCP server) for your system, and any AI application that speaks MCP can use it.

• What it does: lets an AI assistant read data from, and take actions in, systems such as your CRM, order database or internal tools.
• What it does not do: it does not make the AI smarter, and it does not secure your data for you. Permissions, approval steps and logging are still your job.
• Who should care now: businesses whose staff or customers already work inside AI assistants, and software vendors whose customers ask for AI access to the product.
• Who can wait: businesses with no clear task they want an assistant to perform against their own data.

The problem MCP solves

A language model only knows its training data and whatever is placed in the conversation. To do useful work for a business it needs access to live information and the ability to act. Before MCP, each AI product had its own way of plugging in outside systems, so every pairing of an AI application and a business system needed its own integration. Anthropic, which introduced MCP on November 25, 2024, put it this way: "every new data source requires its own custom implementation."

MCP replaces those one-off integrations with a shared protocol. The system owner builds one MCP server. The AI vendor builds MCP support into its product once. After that, the two can work together without a custom project for each combination.

MCP is no longer a single-vendor project. In December 2025 Anthropic donated it to the Agentic AI Foundation under the Linux Foundation, whose platinum members include Amazon Web Services, Anthropic, Google, Microsoft and OpenAI. For a buyer, that matters for one reason: the connector you pay for is less likely to be tied to the fortunes of one AI supplier.

One clarification: MCP is plumbing, not an agent. It is how an assistant or agent reaches your systems, and it says nothing about how the AI plans or decides. For that distinction, see our guide to AI agents vs chatbots vs workflow automation.

How MCP works: hosts, clients and servers

The MCP architecture has three participants.

• Host: the AI application the person actually uses, such as Claude Desktop or Visual Studio Code. It coordinates everything.
• Client: a component inside the host that keeps a connection to one MCP server. The host creates one client per server.
• Server: a program that provides data and actions to the AI application. This is the part a business builds or installs for its own system.

A server can run in two places. A local server runs on the user's own machine and is typically used by one person. A remote server runs on infrastructure you host, is reached over the internet, and typically serves many users. Most business use cases involving shared company data call for a remote server.

What a server can offer: tools, resources and prompts

An MCP server exposes three kinds of building block. The official server concepts guide also says who is in control of each, which is the part business readers should pay attention to.

Tools carry the most value and the most risk, because the model chooses when to use them. In a typical exchange, the AI application asks the server which tools exist, the model reads their names and descriptions, and when a user request calls for one, the application sends a call to the server and passes the result back to the model. The specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations", but how that approval looks is left to each AI product.

Which AI products support MCP today

The following is based on each vendor's own documentation as checked in early October 2026. Capabilities change often, so confirm against the linked pages before committing to a design.

Support is real, but it is not uniform

"Supports MCP" does not mean "supports all of MCP." Copilot Studio documents tools and resources but not prompts. Anthropic states that Claude "implements a subset of the MCP specification", with its own size and timeout limits, and lists features it does not yet support. Each product also has its own rules about which plans can add custom servers and who in an organization is allowed to do so.

The practical consequence: decide which AI products your users actually work in before you build, then design the server around what those products support. A server built only from tools, with clear names and descriptions, is the safest common denominator.

What exposing your business system through an MCP server involves

An MCP server is usually a thin layer in front of an API or database you already have. The protocol work is the small part. Most of the effort goes into deciding what the AI may do and enforcing it. A typical project looks like this, ending with testing inside the actual AI product your users have.

1. Pick the tasks, not the data. Start from two or three jobs a person wants done ("find the status of this order", "list overdue invoices for this customer") and build tools for those. Do not mirror every API endpoint.
2. Start read-only. Reading data is far lower risk than changing it. Add write actions one at a time, once the read tools have proved useful.
3. Identify each user. For a remote server, each person should sign in as themselves so the server can apply that person's existing permissions. The MCP authorization specification is based on OAuth 2.1, the same family of standards behind "Sign in with..." buttons.
4. Enforce permissions on the server. The server must check on every call that this user may see this record. Never rely on the AI to hold back data it has been given.
5. Write tool descriptions carefully. The model chooses tools from their descriptions. Vague or overlapping descriptions cause wrong calls. This is closer to writing instructions for a new employee than writing code.
6. Host, log and monitor. A remote server is a production service. It needs hosting, rate limits, an audit log of who asked for what, and someone responsible for it.

The cost and timeline drivers follow from that list: whether a clean API already exists, how many tools you need, whether any of them change data, how complex your permission model is, whether you have a sign-in system that can issue OAuth tokens, and how many AI products you must support. A read-only server over a well-documented API is a small project. Write actions over a legacy system with no API make it a much larger one, mostly because the API has to be built first.

If your application runs on a mainstream framework, some of the groundwork may already exist. Laravel, for example, ships an official Laravel MCP package for defining servers, tools, resources and prompts inside an existing application, which is one reason an MCP layer fits naturally into a Laravel development project. Official SDKs also exist for other languages.

An illustrative scenario

This is a hypothetical example, not a client case study. A wholesale distributor's account managers spend much of the day answering "where is my order?" The company builds a remote MCP server with three read-only tools: find a customer, list that customer's open orders, and get shipment tracking for an order. Each account manager signs in with their company account, and the server returns only customers assigned to them. Managers can now ask their AI assistant for an order summary before a call. When the company later considers a fourth tool, "issue credit note", it requires explicit confirmation and a value limit enforced by the server, because a wrong credit note costs money.

Security and permission risks

The MCP specification is candid about its limits. It lists user consent, data privacy and tool safety as key principles, then adds that "MCP itself cannot enforce these security principles at the protocol level." The safeguards have to be built by whoever makes the AI product and whoever makes the server. The main risks for a business are these.

• Prompt injection. Text the model reads can contain hidden instructions. If an assistant can read a customer email and also call your tools, a crafted email could try to steer it into misusing them. OWASP ranks prompt injection first in its 2025 list of risks for LLM applications and recommends least-privilege access and human approval for high-risk actions. OpenAI's developer mode documentation gives users a similar warning about prompt injection, model mistakes on write actions, and malicious MCP servers.
• Over-broad permissions. A server connected with one all-powerful service account gives every user, and every successful attack, the same reach. The official security best practices recommend minimal scopes that expand only when a privileged operation is first needed.
• Untrusted third-party servers. Installing someone else's MCP server is installing software. The same guidance notes that a local server can execute any command with the privileges of the application that launched it. Treat public MCP servers like any other dependency: known publisher, reviewed, approved by IT.
• Data leaving your control. Whatever a tool returns is sent to the AI provider as part of the conversation. If that includes personal data, it is a data-sharing decision. In the UK, the ICO publishes guidance on AI and data protection under UK GDPR, which it notes is under review following the Data (Use and Access) Act. In the US, the rules that apply depend on your sector and the states you operate in. In both countries, check your AI provider's data terms and take advice from a qualified professional. This article is not legal advice.

When a business should care, and when to ignore MCP for now

For technical readers

• Wire format and transports. MCP uses JSON-RPC 2.0 over two standard transports: stdio for local servers and Streamable HTTP for remote ones. The older HTTP+SSE transport is deprecated, although some clients still accept it.
• Current revision. The current specification revision is 2026-07-28. Its changelog makes the protocol stateless: the initialize handshake and protocol-level sessions are removed, every request carries its protocol version and client capabilities, and servers must implement a server/discover request. Roots, Sampling and Logging are deprecated, as is OAuth Dynamic Client Registration in favor of Client ID Metadata Documents. Deprecated features have a minimum twelve-month window before removal.
• Clients lag the specification. Anthropic's connector documentation, for example, lists the 2025-03-26, 2025-06-18 and 2025-11-25 authorization specifications as the ones Claude follows. Use a maintained SDK that handles several protocol versions, and test against each target client rather than against the specification alone.
• Authorization. Authorization is optional in the protocol, but any remote server over business data should implement it. Servers act as OAuth 2.1 resource servers, must publish OAuth 2.0 Protected Resource Metadata (RFC 9728), and must validate that each access token was issued specifically for them. Passing a user's token straight through to a downstream API is explicitly forbidden. Local stdio servers take credentials from the environment instead.

Frequently asked questions

What is the Model Context Protocol in simple terms?

It is an open standard that lets AI applications connect to outside systems in a consistent way. A system owner builds an MCP server once, and any AI application that supports MCP can use it to read data or perform actions, subject to the permissions you set.

Is MCP the same as an API?

No. An API is how software talks to your system. An MCP server usually sits in front of an existing API and describes a small set of actions in a form an AI model can discover and call. You still need the API, or direct database access, underneath.

Is MCP only for Claude?

No. Anthropic created it, but it is now governed by the Agentic AI Foundation under the Linux Foundation, and OpenAI, Microsoft and others document support in their own products. The level of support differs by product and plan.

Is MCP secure enough for business data?

MCP defines how authorization should work, but it does not enforce security by itself. A well-built server with per-user sign-in, server-side permission checks, least-privilege access and approval for write actions can be appropriate for business data. A carelessly built one can expose far more than intended.

Conclusion

MCP has become the common way for AI assistants to reach business systems, and the major AI vendors now document support for it. That makes it a reasonable foundation, but not a shortcut: the value comes from choosing the right few tasks, and the safety comes from permissions, approvals and logging that you design yourself.

A practical next step is to write down three tasks you would want an assistant to perform against one of your systems, then check whether that system has an API and a clear permission model. If it does, a read-only pilot is a contained piece of work. If you want a second opinion on scope or on building the API layer underneath, you can talk to Entrant Technologies about your system.