The Model Context Protocol (MCP) is an open standard that connects AI agents to tools, data and business applications through one common interface: you build one MCP server per system and any compatible model can use it. Anthropic released it in November 2024; OpenAI, Google and Microsoft support it, and more than 10,000 public servers exist.
Key Takeaways
MCP has become the standard way to connect AI agents to company systems, and permissions are its main risk.
- MCP (Model Context Protocol) is an open standard created by Anthropic in November 2024 that defines how AI agents access tools, data, and applications. In December 2025 Anthropic donated it to the Agentic AI Foundation, a fund of the Linux Foundation co-founded with Block and OpenAI.
- It solves the N×M problem: instead of building one integration per model-tool combination, you write an MCP server once and any compatible model uses it.
- In the enterprise, the winning pattern is internal MCP servers that expose your CRM, ERP, RAG, and sensitive data to any agent while keeping permissions, auditing, and data residency under control.
- The main risk is not technical: it is permission governance. A misconfigured MCP gives an agent access to more data than it should see. Design with least-privilege from day 1.
What MCP Is and What Problem It Solves
MCP is a client-server protocol, based on JSON-RPC, through which servers offer AI clients tools, resources and prompts. Those are its three capability types:
- Tools: functions the model can invoke (query the CRM, create a ticket, run a SQL query).
- Resources: documents and data the model can read (files, records, dynamic content).
- Prompts: reusable instruction templates the client can invoke.
Any AI model or application that speaks MCP can connect to any MCP server with no new integration code. It is the conceptual equivalent of the Language Server Protocol that VS Code popularized for programming, but applied to AI agents and enterprise tools. The current specification, version 2026-07-28, dropped the initialization handshake of earlier versions: each request declares its protocol version, and the protocol keeps no session between calls.
What MCP is NOT:
- It is not a new AI model. It is a communication protocol, model-agnostic.
- It does not replace your REST API. MCP wraps existing APIs in a standard interface for agents; your APIs stay alive.
- It does not solve governance by itself. It provides the "how to connect"; you still define what is exposed and to whom.
Direct analogy: before USB, every peripheral had its own connector (PS/2 mouse, parallel printer, serial modem). USB unified that. MCP does the same with the "tools" an AI agent needs: instead of an OpenAI Functions connector, an Anthropic Tool Use one, a Google function calling one, there is a single protocol all of them speak.
Why MCP Matters in 2026 (and Why It Was Adopted So Fast)
MCP matters because it turns N×M custom integrations between models and systems into one server per system. The classic problem any company deploying agents faces is N×M: you have N candidate AI models (Claude, GPT, Gemini, open-source) and M internal systems (Salesforce, HubSpot, Jira, SAP, knowledge base). Without a standard, you need N×M integrations, each with its own auth, pagination, errors, and format.
With MCP, you write M servers (one per system) and all N models consume them without modification. This matters for three practical reasons:
- Real vendor lock-in elimination. If you switch from OpenAI to Claude or vice versa, your tool stack does not change. It is the first time switching an LLM provider does not mean rewriting integrations.
- Lower maintenance cost. One implementation per system, not one per model and framework.
- Faster agent composition. Building a new agent that combines 5 internal tools moves from weeks of integration to hours.
Adoption has been very fast precisely because the problem was universal and the solution is technically simple: the dates are in the market data section below.
Comparison: MCP vs Function Calling vs OpenAPI
MCP is the only one of the three that is open, model-agnostic and designed specifically for AI agents.
| Feature | MCP | Proprietary Function Calling (OpenAI/Anthropic/Google) | OpenAPI / Generic REST |
|---|---|---|---|
| Open standard | Yes, hosted by the Linux Foundation's Agentic AI Foundation | No, per provider | Yes (industry) |
| Portability across AI models | Total | None without rewriting | Partial (not AI-specific) |
| Dynamic tool discovery | Yes, via protocol | Manual | Not natively |
| Built-in auth and permissions | Yes (authorization framework based on OAuth 2.1) | Yes, different per provider | Yes (multiple standards) |
| Result streaming | Yes | Yes | Limited |
| Resources (data, not just functions) | Yes, first-class | Limited | Designed for data |
| Ready-to-use server ecosystem | More than 10,000 public servers (December 2025) | N/A | Generic |
| AI-agent compatibility | Designed for them | Designed for them | Not optimized |
MCP does not replace OpenAPI: REST APIs remain the source of truth. A typical MCP server is a thin layer that wraps your existing API and exposes only what the agent should see, with the permissions you decide.
When MCP Makes Sense in Your Business
MCP makes sense when you run more than one AI agent that needs your internal tools.
Yes, clearly:
- You are deploying or about to deploy more than one AI agent that needs internal tools.
- You want flexibility to switch AI models (from GPT to Claude, or try open-source) without redoing integrations.
- You have sensitive data that cannot go to an AI cloud, but you want agents to query it under control.
- Your team builds agents in multiple frameworks (n8n, LangGraph, custom code) and wants a shared tool layer.
- You want to expose internal services (CRM, ERP, knowledge base) to tools like Claude Desktop, Cursor, or enterprise ChatGPT securely.
Not yet:
- You only have one simple agent with two well-bounded integrations. Native function calling is enough.
- Your stack is 100% on a single proprietary provider (e.g., pure Microsoft Copilot Studio) and you do not plan to leave it.
- You lack resources to govern permissions correctly on MCP servers. Without governance, MCP amplifies risks.
Key Market Data
MCP went from Anthropic's release to support by OpenAI and Google in under six months.
- When it donated MCP to the Agentic AI Foundation, Anthropic reported (December 2025) more than 10,000 active public MCP servers and more than 97 million monthly SDK downloads across Python and TypeScript.
- According to GitHub Octoverse 2025, MCP "hit 37k stars in just eight months".
- The Linux Foundation (December 2025) lists Claude, Cursor, Microsoft Copilot, Gemini, VS Code and ChatGPT among the products that adopted MCP.
| Date | Milestone | Source |
|---|---|---|
| 25 November 2024 | Anthropic open-sources MCP | Anthropic |
| 26 March 2025 | OpenAI adds MCP support to its Agents SDK | OpenAI Agents SDK v0.0.7 |
| 10 April 2025 | n8n ships the MCP Client Tool and MCP Server Trigger nodes (version 1.88.0) | n8n |
| 20 May 2025 | Google announces MCP support in the Gemini SDKs | Google for Developers |
| 21 May 2025 | OpenAI adds remote MCP servers to the Responses API and joins the MCP steering committee | OpenAI |
| 9 December 2025 | Anthropic donates MCP to the Agentic AI Foundation (Linux Foundation) | Linux Foundation |
| 10 December 2025 | Google Cloud launches fully managed remote MCP servers, starting with Maps, BigQuery, Compute Engine and GKE | Google Cloud |
| 28 July 2026 | Current specification version, without initialization handshake | modelcontextprotocol.io |
Real-World Use Cases in B2B Companies
Companies use MCP mainly to share one integration across several agents and to give AI clients controlled data access.
Case 1: Corporate MCP server over Salesforce + RAG base
- Problem: a consultancy had Claude agents for commercial analysis and another GPT agent for proposal generation. Each had its own Salesforce integration, and the RAG base over historical proposals was duplicated in two places.
- Solution: single MCP server exposing Salesforce query tools (with role permissions) and RAG resources. Both agents consume it without modification.
- Stack: custom MCP server (TypeScript) + Salesforce REST API + Qdrant (RAG) + corporate OAuth.
- Result: maintenance reduced to a single implementation. Switching AI provider is now a commercial decision, not a technical one.
Case 2: Secure Claude Desktop access to the data warehouse
- Problem: analysts wanted to use Claude Desktop to explore BigQuery data, but opening direct access from an AI client was not safe.
- Solution: intermediate MCP server that validates user identity (SSO), translates requests into parameterized SQL, applies row-level security, and returns only data the user is allowed to see.
- Stack: MCP server in Python + BigQuery + Okta (SSO) + full audit in Datadog.
- Result: Claude becomes a natural interface over the data warehouse without bypassing any existing access control.
Case 3: Tech support agent with MCP to Jira, GitHub, and Confluence
- Problem: an L2 support team spent hours searching across Jira tickets, GitHub code, and Confluence docs to resolve incidents.
- Solution: AI agent in LangGraph connected to three MCP servers (one per system). The agent searches, correlates, and proposes resolution with citations to sources.
- Stack: LangGraph + Anthropic Claude + official Atlassian and GitHub MCP servers + custom MCP server for internal Confluence.
- Result: support team's first response time cut in half. Full traceability: every agent answer cites the consulted sources.
How to Deploy MCP in Production: Step by Step
Deploying MCP in production takes eight steps, from choosing the first systems to monitoring abuse.
Identify the 3-5 internal systems most used by your agents. Start with those you already have manually and duplicately integrated. CRM, RAG base, ticket system are usually first.
Install existing MCP servers before building your own. There are official servers for GitHub, Slack, Postgres, Google Drive, Notion, Linear, etc. Reuse them when they cover 80%+ of your case.
Build your own MCP servers only for internal systems or specific logic. There are official SDKs for TypeScript, Python, C#, Go, Rust, Ruby, Java, Swift, PHP and Kotlin. Learning curve is hours if you already know REST APIs.
Define permissions at tool and resource level. Each connecting agent must have a profile listing which tools it can invoke and which resources it can read. Least-privilege principle.
Implement robust auth. OAuth for end-user access, service tokens for unattended agents. Never shared tokens.
Add full auditing. Every client-to-server MCP call must log: which agent, which user, which tool, which arguments, which response. The MCP specification recommends that clients "log tool usage for audit purposes"; the EU AI Act only makes automatic logs mandatory for high-risk systems (Article 12).
Deploy on controlled infrastructure. For sensitive data, self-host MCP servers. For non-critical cases, third-party MCP-as-a-Service may suffice.
Monitor usage and abuse. Error rates, unusual calls, agents querying more data than expected. It is a new attack surface.
Common Mistakes (and How to Avoid Them)
The most common MCP mistake is exposing a whole database through a single generic server.
Mistake: exposing your full database via a single MCP server → Reality: you give the agent access to everything, including what it should not see. Design specific tools and fine-grained permissions, not a generic "execute SQL" endpoint.
Mistake: using MCP when a simple API would do → Reality: if you have one agent with two trivial integrations, MCP adds complexity without return. Reserve MCP for when the ecosystem grows.
Mistake: ignoring auth because "it is internal" → Reality: the day an agent misbehaves or an MCP server is exposed, no auth means a breach. OAuth or tokens, always.
Mistake: not versioning your MCP servers → Reality: production agents depend on tool signatures. Changing arguments without versioning breaks agents silently.
Mistake: trusting public MCP servers without auditing them → Reality: an MCP server is code that runs actions against your systems. Audit it like any critical dependency.
Mistake: no rate limiting → Reality: an agent with a bug can invoke the same tool in a loop and saturate your system. Per-agent and per-tool limits are mandatory, and the specification requires servers to rate limit tool invocations.
Realistic Timelines and ROI
Adopting an existing MCP server takes hours to days; building your own takes one to three weeks.
Implementation time:
- Adopting an existing MCP server for a supported system: hours to days.
- Building your own MCP server for an internal system: 1-3 weeks depending on complexity and permissions.
- Migrating existing integrations to a corporate MCP architecture: 2-4 months depending on current volume.
Time to ROI:
- If you deploy 2+ agents that share tools: ROI from the second agent. The first reuse already pays back.
- AI provider switching (lock-in): savings materialize when it happens. A switch that used to take months becomes days.
Metrics to measure from day 1:
- Number of active MCP servers and their usage rate.
- Calls per agent, per tool, per user.
- Errors and latency per endpoint.
- Audit coverage: % of calls with full traceability.
- Reduction in integration code lines after adopting MCP.
MCP-Specific Security Risks
MCP's main security risks are tool poisoning, accumulated permissions, prompt injection through resources and accidental network exposure.
- Tool poisoning: a malicious or compromised MCP server can describe its tools with deceptive instructions that the agent follows, and the official MCP security guide also warns about servers that change their tool definitions after you approved them. Only connect servers you control or from reputable providers.
- Permission accumulation: an agent consuming several MCP servers has the sum of their privileges. Audit the set, not just each server.
- Prompt injection via resources: a malicious document returned by a resource may contain instructions for the model. Filter and sanitize external content.
- Unintended exposure: a poorly configured local MCP server can become network-accessible. Restrict to localhost where applicable and use firewall in other cases.
The official documentation includes security best practices, and the specification states that clients must treat tool annotations as untrusted unless they come from trusted servers.
Frequently Asked Questions
What is the difference between MCP and the old ChatGPT plugins?
ChatGPT plugins were OpenAI-proprietary, lived on their infrastructure, and worked only with their models. MCP is open, lives wherever you deploy it, and works with any compatible model. Portability and control are the difference.
Do I need MCP if I only use Claude or only use ChatGPT?
Yes if you plan to grow in number of agents or want protection from a future provider switch. If you only have one simple, isolated case, native function calling is enough today.
Is MCP secure for sensitive data?
As secure as you configure it. The protocol supports OAuth, service tokens, and fine-grained permissions. The critical part is governance: defining well what each server exposes and to whom. For regulated sectors, self-host the servers on controlled infrastructure.
How does MCP fit with the EU AI Act?
It fits well if you take advantage of it: it lets you trace every agent action (which tool was called, with what data, what was returned). The AI Act makes automatic logs mandatory for high-risk systems (Article 12), from 2 December 2027 for those in Annex III, so design your logging from the start.
Can I use MCP with n8n, LangGraph, or open-source frameworks?
Yes. n8n added native MCP nodes in April 2025 (version 1.88.0), and LangChain, LangGraph and LlamaIndex have official MCP integrations. Open-source frameworks have adopted MCP as the standard tool layer.
What about MCP servers offered by AI SaaS providers?
There is a growing "MCP-as-a-Service" ecosystem where a provider gives you a managed MCP server against common tools (HubSpot, Slack, etc.). Useful to avoid maintenance, but check where data lives and what auditing is offered.
Do I need a dedicated team for MCP?
Not at first. Starting with existing servers and a couple of your own can take a developer with API experience 1-2 weeks. As the catalog grows, assign clear ownership: someone responsible for the servers and permissions.
Ready to Build a Portable, Secure AI Agent Stack?
NAXIA deploys MCP-based architectures for European companies that want AI agents without lock-in. We give you real control over data and permissions. If your team already has multiple agents or plans to grow, let's talk: no commitment, no 40-slide decks.
Book your free first consultation
Or, if you prefer, explore our implementation process first.
NAXIA is a Spanish artificial intelligence and automation agency for companies of all sizes: it designs, deploys and maintains AI agents, voice agents and automations integrated with each client's systems. Founded in 2024 and based in Pamplona (Navarre), it works with companies across Spain and has delivered more than 20 projects.