What is MCP? How to connect AI safely to tools, data and business software

A language model can analyse, write and program, but without access to your systems it remains a clever conversation partner that cannot look anything up or act on it. The Model Context Protocol (MCP) is the standard that gives AI applications that access: to files, databases, APIs and business software. It makes connecting easier. It does not make connecting safe by default, and that is where things usually go wrong in practice.

What is the Model Context Protocol?

MCP is an open protocol that lets AI applications discover, in a consistent way, which data and functions an external system offers, and then use them. It is not an AI model and not a replacement for an API. It is a standardised layer between an AI application and the systems that provide context or actions.

Anthropic introduced MCP on 25 November 2024. On 9 December 2025 Anthropic moved it to the Agentic AI Foundation, a directed fund under the Linux Foundation that it co-founded with Block and OpenAI. The protocol no longer belongs to a single AI vendor. At the time, Anthropic reported more than ten thousand active public MCP servers and over 97 million SDK downloads a month, and listed ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code among the adopters.

What problem does MCP solve?

Without MCP you build every integration separately. Connecting an AI assistant to GitHub, Google Drive, Slack and an internal database means four integrations, each with its own authentication, endpoints, data structures and error messages. And those integrations only work in the one AI application you built them for.

There is an AI-specific problem on top of that. Regular software knows in advance which endpoint to call. A language model first has to decide which tool is relevant, which arguments it needs and whether the result is enough to continue. MCP standardises exactly that part: a server describes the data and actions it offers and the parameters each action expects. Any MCP-compatible application can then use that server.

MCP is often compared to a USB-C port for AI: one connector for many devices. That holds for the plug. But a USB stick you plug in cannot send an email on your behalf. With MCP, besides the connection, you also have to settle who may do what, which actions need approval and how you validate input. The protocol makes the connection uniform; it does not decide which actions are safe or desirable.

Host, client and server

According to the MCP specification, an implementation has three roles.

• The host is the application in which the user works with AI: a desktop assistant, code editor or custom agent platform. The host manages the interface, the language model, permissions and connections.
• The client lives inside the host and maintains the connection to one MCP server. A host working with three servers has three clients.
• The server exposes data or functions: locally (reading files, for example) or remotely (a CRM, repository or SaaS platform). A server is often a controlled wrapper around an existing REST, GraphQL or database interface.

Messages are JSON-RPC 2.0: a fixed structure for requests, responses, notifications and errors.

What changed in the July 2026 specification?

On 28 July 2026 the 2026-07-28 specification was released, the largest revision since launch. The main difference: MCP is now stateless. Previously every connection began with an initialisation handshake in which client and server agreed on the protocol version and supported features, and an HTTP server kept track of a session. That handshake and those sessions are gone. Every request now carries its own protocol version and client capabilities, and servers offer a server/discover call a client can use to find out up front what the server supports.

Why it matters: any request can now land on any server instance, so an MCP server scales behind an ordinary load balancer like any other web service. If a server does need state across several calls, such as a shopping cart, it returns its own handle that the client passes back as an ordinary argument.

Roots, Sampling and Logging have also been deprecated. They keep working for at least twelve months, but new implementations should not adopt them. Existing servers won't break overnight, but if you build a server now, build it on the new version.

Local or remote: stdio and Streamable HTTP

MCP defines two standard transports.

stdio: the client launches the server as a local subprocess and communicates over standard input and output. This is the form for local developer tools, such as a server allowed to read a project folder. Keep in mind that a local MCP server is simply code running on your computer with your permissions. Don't install one without checking the source code, the publisher and the permissions it asks for.

Streamable HTTP: each message is an HTTP POST to a single endpoint of an independently running server; the reply comes back as JSON or as a stream (Server-Sent Events) tied to that one request. This is the form for central business integrations and SaaS services, such as a server in a locked-down cloud environment that gives access to a CRM.

Tools, resources and prompts

An MCP server offers three kinds of building blocks, each steered by a different party.

Tools: actions the model can request

A tool is an executable action: searching for candidates in a recruitment database, creating a GitHub issue, running a query, scheduling an appointment. A tool has a name, a description and an input schema, so the model can decide when it is relevant and which arguments it needs.

The specification calls tools model-controlled: the model proposes calling a tool. That does not mean every proposed action gets executed. The specification says hosts must obtain explicit user consent before invoking a tool.

Resources: context from other systems

Resources supply data that serves as context: a file, a database schema, a log file or a document, each identified by a URI. Resources are application-controlled: the host decides how and when that information reaches the model. The difference from a tool: a resource provides information, a tool does something.

Prompts: reusable templates

Prompts are templates or workflows the user picks, for example as a slash command. They are user-controlled. A Git server could offer a prompt for reviewing recent changes, taking a branch name as an argument.

How does a client find out what a server can do?

A client can ask a server which tools, resources and prompts it offers. A tool description looks like this:

{
  "name": "search_candidates",
  "description": "Search candidates by role, region and skills",
  "inputSchema": {
    "type": "object",
    "properties": {
      "role": { "type": "string" },
      "region": { "type": "string" },
      "skills": {
        "type": "array",
        "items": { "type": "string" }
      }
    },
    "required": ["role"]
  }
}

So the model doesn't need to be programmed against a specific endpoint in advance. It gets a plain-language description and an input schema. That is not maintenance-free: when you change a tool, the description, schema, tests and authorisation rules have to change with it.

MCP or a regular API?

MCP doesn't replace APIs; most MCP servers use one. An API is built for software that knows exactly which endpoint it needs. An MCP server translates the relevant functions of that API into tools and resources an AI application can discover on its own. The host decides which of them the model gets to see, the model picks a suitable action, and the host oversees permission, execution and result.

For a single, simple, fixed integration in one application, direct function calling or your own API wrapper is often more practical. MCP pays off when several AI applications need the same systems, when you want to offer an integration independent of any vendor, or when tools need to be discovered dynamically.

Two practical examples

An assistant for software maintenance

Suppose you connect three MCP servers: one for the Git repository, one for the issue tracker and one for technical documentation. You ask:

Find out why issue 184 hasn't been resolved yet, check the relevant code and propose a patch.

The model reads the issue, finds the relevant code and pulls in documentation. The result is an analysis and a proposed patch. Editing files or opening a pull request sits behind an approval step, so write actions stay with the developer.

Combining recruitment data

Suppose a recruitment organisation exposes a CRM, a mailbox and a candidate platform through MCP. A recruiter asks:

Give me the open Java vacancies in Gelderland and find candidates we've been in touch with in the past six months.

The agent fetches the vacancies from the CRM, searches the candidate platform by skills and region, and checks through a separate integration when the last contact took place. MCP makes the integrations uniform, but the questions that matter stay with the organisation: may the model only read? May it draft emails? May it approach candidates on its own? Every action needs an explicit rule, especially with personal data involved.

MCP, agents and A2A

An agent turns a goal into steps, selects tools, evaluates results and decides the next step. MCP provides the connection to tools and data, but not the agent logic itself: planning, memory, evaluation, retries and approval flows are handled by the host or the agent framework. OpenAI's agents documentation, for instance, lists support for MCP servers.

MCP is not the same as Agent2Agent (A2A), the protocol Google announced in April 2025 and moved to the Linux Foundation in June 2025. MCP connects an AI application to tools and data sources; A2A handles communication and task hand-off between agents. A travel agent could use MCP to query a flight database and A2A to give a separate hotel agent a task.

Security: access is not safety

As soon as an AI can reach mailboxes, databases or production environments, security outweighs convenience. The specification says so itself: MCP cannot enforce these principles at the protocol level, so it is up to whoever implements it. The official security best practices describe the attacks in concrete terms. What follows from them:

Least privilege. Give each server and user only what they need. An analysis assistant usually only needs read access. The guidelines recommend starting with a small set of scopes and asking for more only when an action requires it; otherwise one stolen broad token opens everything.

Approval for risky actions. Searching documentation carries a different risk from sending an email or changing production data. Require explicit confirmation for external communication, financial transactions, deletions and changes to critical systems.

Tokens only for the right recipient. For HTTP-based connections MCP uses authorisation based on OAuth 2.1. An MCP server must not accept a token that was not issued to it, and must not pass a client's token unchecked to a downstream API. This "token passthrough" is explicitly forbidden in the specification.

Secrets out of the code. API keys and tokens don't belong in source code or configuration files that end up in version control. Use a secret manager, protected environment variables and short-lived tokens.

Tool output is untrusted input. Data from an external document can contain instructions that mislead the model: indirect prompt injection. Treat tool results as untrusted and make sure text from a document never grants extra privileges. The specification goes one step further: even the descriptions of tools themselves should be treated as untrusted unless they come from a trusted server.

The hidden costs: tokens, latency and wrong choices

Every tool you offer costs tokens, because its name, description and input schema are passed to the model. Many similar tools also make it more likely the model picks the wrong one. Remote servers add network round trips, so a workflow with ten tool calls shows up in the waiting time.

• Offer only the tools relevant to the task.
• Write short, unambiguous descriptions and avoid tools that do almost the same thing.
• Measure token usage and response times.
• Log tool calls, but no more sensitive data than necessary.
• Test time-outs and failure scenarios too, not just the actions that succeed.

Start with one workflow, not ten servers

The value of MCP is not AI roaming through your systems unsupervised. It is controlled integration: one protocol, clear schemas, limited permissions and visible approval steps. A good implementation therefore doesn't start with how many tools you can connect, but with which data and actions an AI needs for one concrete workflow. Keep that set small, measure what it costs and put every write action behind an approval. If you work with Claude Code, you connect such a server with claude mcp add; how to work with it effectively is covered in a separate article.