MCP

On its own, a language model can neither look into a CRM nor book a meeting; the AI application needs connections to other systems. Without a standard, every vendor builds every connection itself, and every new pairing of application and system becomes its own project. MCP defines what that connection looks like: an MCP server exposes the functions and content of a system, and an AI application, as a client, accesses them through MCP as one shared interface. A server built once works with any application that supports the protocol. The project documentation compares MCP to a USB-C port for AI applications.

Anthropic introduced MCP as an open standard on November 25, 2024. According to Anthropic, ChatGPT, Gemini, Microsoft Copilot, Visual Studio Code and Cursor, among others, have adopted the protocol. On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. The specification is published in dated revisions; the current one is dated July 28, 2026.

For executives, MCP determines how quickly AI applications can be hooked up to the company's own systems and how easily the application or model can be switched. At the same time, every server opens a door to data and actions. What an AI may see and do through that door is not governed by the protocol but by how it is set up. Rolling out MCP is therefore largely a question of access rights.

How MCP works at its core.

MCP has three roles. The host is the AI application a person works with, e.g. an assistant, a chat app or a development environment. Inside the host sits one client per connection. The server is a separate program that connects a specific system, such as a document search, a ticketing system or a database. Messages between client and server follow the JSON-RPC 2.0 format.

A call works like this. The client asks the server what it offers. The server describes its tools with a name, a plain-language description and the inputs it expects. The language model reads those descriptions and decides, for a given request, whether to use a tool and which one. The client sends the call, the server runs it in the connected system and returns the result, which feeds into the answer.

The specification defines two ways to connect. With stdio, the application launches the server as a local program on the same machine. With Streamable HTTP, the server runs as a network service, and each message is sent as a request to a single endpoint. Since the July 28, 2026 revision, the protocol is stateless: every request carries all the information it needs.

Tools, resources and prompts.

An MCP server can offer three kinds of capabilities. Tools are functions the model executes: run a search, create a record, send a message. Resources are content that serves as context, such as files, records or documents. Prompts are prepared instructions or workflows that a user picks on purpose.

The client can offer things to the server as well. Through elicitation, a server can ask the user for a missing detail or a confirmation in the middle of a task. Through sampling, a server could ask the client's language model for a response; the specification of July 28, 2026 marks sampling, roots and logging as deprecated and recommends calling the provider's API directly. Further capabilities come as optional extensions, for example for long-running tasks or for interface elements that appear right in the conversation.

For setting MCP up in a company, the most important split is between reading and acting. A resource or a pure search tool shows content. A tool that writes, sends or deletes changes data and can have consequences outside the system. Such tools need their own approval and confirmation by a person before they run. Every call gets logged.

MCP, APIs and tool use compared.

An application programming interface (API) is built for developers. It defines how one program calls another and assumes someone writes that call in code. MCP does not replace APIs. An MCP server usually uses a system's existing API and describes its functions so that a language model can find and choose them on its own.

Tool use, also called function calling, is a model's ability to produce a function call instead of a text answer. That ability existed before MCP, but every application had to build in its tools itself. MCP standardizes how tools are provided, discovered and called, across applications and model providers.

That is the main benefit. Without a shared standard, every pairing of AI application and system needs its own integration. With MCP, you build one server per system and one client per application, and they all fit together. Switch the application or the model, and you keep your servers.

MCP also differs from RAG in kind. RAG is a method for retrieving knowledge; MCP is an interface. A RAG search can be connected as a tool through MCP.

Security: every server is a door.

The specification is blunt. Tools represent arbitrary code execution and must be treated with appropriate caution. The host must obtain the user's explicit consent before invoking any tool, and tool descriptions are to be considered untrusted unless they come from a trusted server. The specification also states that MCP cannot enforce these principles at the protocol level. They rest with whoever builds and runs the applications and servers.

In practice, a tool returns content, such as an email or a web page, and that content can carry hidden instructions to the model (prompt injection). A tampered tool description can steer the model into calls nobody wanted. Local servers run with the same privileges as the application that launches them, which gives them access to files and credentials on the machine. Adding a server from an unknown source therefore means installing someone else's software.

For remote servers that require sign-in, the specification's security guidance forbids token passthrough: a server may only accept tokens that were issued explicitly for it. Anyone buying or commissioning servers should ask about exactly these points.

Permissions and approvals belong in the setup.

MCP does not decide what a user may see or do. Permissions and approvals have to be set up to match, at the point where the server accesses the connected system. An instruction to the model such as “Do not show confidential data” is no substitute for an access check.

For remote servers, the specification describes an authorization flow based on OAuth, the widely used standard for delegated access. Local servers instead take their credentials from the environment they run in. In both cases, the principle of least privilege applies: a server gets only the permissions its task requires, and more only when they are actually needed. The security guidance explicitly lists broad catch-all permissions such as full access as a common mistake.

The safest setup has the server act on behalf of the person asking and with that person's permissions, not through a shared account that can see everything. The assistant then finds only what the person could open without it. Add to that a list of approved servers, confirmation by a person before consequential actions and a log that records every call with user, tool and result.

What a good implementation looks like.

A good MCP rollout starts with an inventory: which systems should be connected, what data lives there, and which actions are allowed? Ready-made servers exist for many common systems, from the vendors or from the developer community. Their origin, maintenance status and permissions should be checked before use.

Other signs of quality: read and write tools are separate, and write tools require confirmation. Servers act with the permissions of the person asking. Tool descriptions are reviewed and re-approved when they change, because they steer the model's behavior. Every call is logged. It is clear who runs a server, updates it and shuts it off in an emergency. And it is known which revision of the specification servers and applications speak, because the protocol keeps evolving in dated versions.

Answer quality depends on well-organized data and clean approvals, hardly on the protocol. MCP makes the connection easy. What may flow through it is the company's decision.

Where the term stops working

MCP carries requests; it does not check their content. The protocol does not decide which data a user may see or which actions they may take; permissions and approvals have to be set up to match. MCP is distinct from RAG, a method for retrieving knowledge, and from tool use (function calling), a model's ability to call functions; MCP standardizes how those functions are provided.