What is MCP? The short answer
MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems: data sources (files, databases), tools (search, calculators, messaging) and workflows. Instead of writing a separate connector for every “AI app – system” pair, a business builds one MCP server and any MCP-compatible AI application can reuse it.
The official documentation compares MCP to “a USB-C port for AI applications”: one standard plug instead of many proprietary cables. Anthropic announced and open-sourced MCP on 25 November 2024; since December 2025 the project has been hosted by the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. The latest specification at the time of writing is version 2026-07-28.
For a business, the practical question is not whether to follow the MCP trend, but whether several AI agents or AI tools need to reach the same data with controlled permissions. The rest of this guide helps you answer that.
The problem MCP solves: N×M integrations
In its announcement, Anthropic described the core problem: even the most capable models are constrained by isolation from data, trapped behind information silos and legacy systems, and every new data source requires its own custom implementation. MCP replaces those fragmented integrations with a single protocol.
A simple way to see it: if a company has N AI applications (an internal chat assistant, a coding tool, a customer-service AI Agent) and M systems (CRM, document store, ERP, ticketing), the traditional approach can require up to N×M connectors. With MCP, each system needs one MCP server and each AI application needs MCP client support, so the integration effort moves toward N+M.
- Illustrative example: a company with 3 AI tools and 5 internal systems would write and maintain 15 point-to-point connectors. With MCP it builds 5 MCP servers and picks 3 AI tools that support MCP.
- A side benefit: access control, logging and oversight live in the MCP server, which your engineering team owns, instead of being scattered across many integration scripts.
MCP architecture: host, client and server
The MCP specification uses JSON-RPC 2.0 messages and splits a system into three roles. The design takes inspiration from the Language Server Protocol, which standardised how editors support programming languages across an ecosystem of tools.
What host, client and server do
- Host: the AI application that initiates connections, such as a chat app, an IDE or an AI Agent built in-house.
- Client: the connector inside the host; each client talks to one server.
- Server: the service that provides context and capabilities, for example an MCP server for a document store, a database, GitHub or a calendar.
Three server building blocks: tools, resources, prompts
An often-missed point is that each block is controlled by a different party, which directly shapes how you design permissions.
- Tools: functions the model can call, such as searching flights, sending messages or creating calendar events. Tools can write to databases, call external APIs or modify files. Controlled by: the model.
- Resources: read-only data used as context, such as file contents, database schemas or API documentation; each resource has its own URI. Controlled by: the application.
- Prompts: pre-built instruction templates such as “summarise my meetings” or “draft an email”, explicitly invoked by the user (often as slash commands). Controlled by: the user.
Client features and extensions
On the client side there is Elicitation: a server can ask the user for additional information. Version 2026-07-28 deprecated Roots, Sampling and Logging; they keep working for at least twelve months, but new implementations should not adopt them. Beyond the core protocol there are opt-in extensions such as Tasks (long-running work) and MCP Apps (interactive UI rendered inside the conversation).
Transports: stdio and Streamable HTTP
A transport is the channel that carries messages between client and server. The current specification defines two standard transports, and protocol semantics are identical on both.
- stdio: the server runs as a subprocess launched by the client on the same machine and exchanges messages over standard input and output. Suits local tools and developer workstations.
- Streamable HTTP: each message is an HTTP POST to a single MCP endpoint; replies arrive as a JSON object or a request-scoped SSE stream. Suits remote MCP servers serving many users.
- The legacy HTTP+SSE transport is deprecated; migrate to Streamable HTTP.
MCP security: authorisation, least privilege and prompt injection
The MCP specification states plainly that the protocol enables arbitrary data access and code execution paths, and that MCP itself cannot enforce security principles at the protocol level. Responsibility sits with implementers. This is where a business should invest the most.
Principles from the specification
- User consent and control: hosts must obtain explicit user consent before invoking any tool and before exposing user data to servers.
- Tools represent arbitrary code execution; descriptions of tool behaviour (annotations) should be treated as untrusted unless obtained from a trusted server.
- Resource data must not be transmitted elsewhere without user consent.
Authorisation and least privilege
- For remote MCP servers, use the authorisation flow defined in the specification (OAuth-based) rather than shared API keys.
- No token passthrough: an MCP server must not accept tokens that were not explicitly issued for it. The official security guidance lists this as a forbidden anti-pattern.
- Design minimal scopes with step-up elevation; avoid wildcard scopes such as “*”, “all” or “full-access”.
- Local servers run with the client’s privileges: sandbox them, restrict file and network access, and show the full startup command before the user consents.
- For MCP clients deployed on servers, mitigate SSRF: require HTTPS, block private IP ranges and cloud metadata endpoints.
Prompt injection through tools and data
Content returned by a tool or resource (an email, a web page, a support ticket) can carry malicious instructions that steer the model into calling another tool, for example to send data out. Tool descriptions from untrusted servers are another attack channel. Treat every MCP server output as untrusted data, separate read tools from write tools, and require human approval for consequential actions. See What is prompt injection: AI Agent security for businesses and how to design approval points in human-in-the-loop.
MCP vs a plain API vs function calling
MCP does not replace APIs. Most MCP servers wrap a system’s existing API. Function calling (tool use) is a model’s ability to propose calling a function; MCP is the standard for packaging, discovering and calling those functions across many applications.
| Criterion | Plain API (REST/GraphQL) | A model provider’s function calling | MCP |
|---|---|---|---|
| Purpose | Application-to-application calls | Model proposes calls to functions declared by the developer | Standard for connecting AI apps to data, tools and workflows |
| Who decides to call | Code written by developers | Model proposes, application code executes | Model calls tools; application selects resources; user picks prompts |
| Capability discovery | Documentation, OpenAPI | Declared manually in each request | Discovered via tools/list, resources/list, prompts/list |
| Reuse across AI apps | Integration layer per application | Format usually tied to one provider | One server works with many MCP hosts |
| Security controls | Per API design | Built by each application | Consent and authorisation principles in the spec; still implemented by you |
| Best fit | Fixed system integration, no AI | One app, a few functions, one model | Many AI apps, many systems, central governance |
When a business needs MCP, and when it does not
Consider MCP when
- You have, or will soon have, two or more AI applications that need shared access to internal data (for example a staff assistant and an AI Agent handling support tickets).
- Your teams use AI tools that already support MCP (the official docs list Claude, ChatGPT, Visual Studio Code and Cursor) and you want to connect them to company systems.
- You want permissions, logging and approvals in one intermediate layer instead of inside every application.
- You sell software/SaaS and want customers to connect your product to their own AI Agents.
You probably do not need MCP yet when
- There is one application, one model and a few simple functions: direct function calling is usually leaner.
- The process is fixed automation where the model does not need to choose tools: a conventional integration or workflow is easier to test.
- Data is not yet classified and access rules are undefined: do data governance first.
- Nobody owns operating and securing the server: an MCP server is software that needs patching and monitoring like any other service.
A note on context cost
Anthropic notes that once too many servers are connected, tool definitions and intermediate results can consume many tokens in the context window, slowing agents and increasing cost. Enable only the servers and tools each task actually needs.
MCP rollout checklist for businesses
The list below is the process EYC recommends in integration consulting, based on the specification and the official security guidance. Pair it with an AI Agent operating model to define who approves and who is accountable.
| Step | What to do | Check question |
|---|---|---|
| 1. Pick a use case | Choose a measurable process, read-only first | If the AI is wrong, what is the impact? |
| 2. Inventory systems | List systems, sensitive data and owners | Which data must never enter the context? |
| 3. Choose servers | Prefer official vendor servers or build your own; review third-party server code | Who maintains and patches it? |
| 4. Design permissions | Minimal scopes, separate read and write tools, no token passthrough | If a token leaks, how far does the damage reach? |
| 5. Choose transport | stdio locally; Streamable HTTP with authorisation remotely | Is the server exposed to the internet? |
| 6. Approval points | Require human approval for write, send, delete and payment actions | Which actions cannot be undone? |
| 7. Defend against prompt injection | Treat tool output as untrusted; red-team before go-live | Have you tried injecting malicious instructions into data? |
| 8. Logging and monitoring | Log every tool call, caller and result | Can you trace an incident end to end? |
| 9. Pilot, then scale | Run with a small group, measure, then add servers | Are stop and rollback criteria defined? |
| 10. Track versions | Follow the spec changelog and deprecation policy | Which version do your servers and SDKs support? |
Where MCP stands: versions, governance and ecosystem
The MCP specification is versioned by date. Published revisions are 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25 and the current 2026-07-28. According to the official blog, 2026-07-28 makes the protocol core stateless (removing protocol-level sessions and the initialize handshake), hardens authorisation, formalises the extensions framework and introduces a deprecation policy with at least twelve months before a feature can be removed.
On governance, on 9 December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. According to the project blog, MCP keeps full autonomy over its technical direction; protocol decisions are still made by the maintainers through the SEP proposal process. For businesses, this reduces dependence on any single vendor.
EYC advises on and implements integrations between AI Agents and business systems, including MCP server design, permissions and monitoring. Learn more about integration consulting or AI automation.
Frequently asked questions
What does MCP stand for?
MCP stands for Model Context Protocol, an open standard for connecting AI applications to external data sources, tools and workflows. Anthropic announced it on 25 November 2024; the project now sits in the Agentic AI Foundation under the Linux Foundation.
What is an MCP server?
An MCP server is a program that exposes a system’s capabilities (a document store, database, GitHub, calendar and so on) to AI applications through the MCP standard. It offers three building blocks: tools the model can call, read-only resources for context, and prompt templates the user chooses.
Does MCP replace APIs?
No. Most MCP servers wrap existing APIs so AI applications can discover and call them in a uniform way. APIs remain the foundation of system-to-system integration; MCP is a standard layer on top for AI applications.
What is the difference between MCP and function calling?
Function calling is a model’s ability to propose calling a function declared by an application. MCP is a standard for packaging and sharing those functions, data and prompt templates across many AI applications, with discovery and authorisation built in.
Is MCP secure?
MCP is not secure by default. The specification requires user consent before tool invocation and states that the protocol cannot enforce security at the protocol level. Businesses need proper authorisation, least privilege, sandboxing for local servers, prompt injection defences and logging.
What is the latest MCP version?
At the time of writing (October 2026), the latest specification is version 2026-07-28, released on 28 July 2026, with a stateless protocol core and a formal extensions framework.