MCP · AI CONCEPT
What is MCP (Model Context Protocol)? Tool-use standard May 2026
MCP is an open standard for LLM access to tools, data and servers. Anthropic spec Nov 2024, adopted by OpenAI/Google/Microsoft as of May 2026.
Researched & fact-checked by: DuneDive LLC · As of: 2026-05
What is MCP?
MCP stands for Model Context Protocol. It is an open standard specifying how language models access tools, data sources and external servers. Instead of every LLM provider (OpenAI, Anthropic, Google) prescribing its own proprietary tool-use format and each integration being built individually, MCP defines a single language.
Anthropic published MCP in November 2024 as an open-source specification (modelcontextprotocol.io, Apache 2.0). The idea was simple: tool-use APIs should be standardised like HTTP for web servers. In 2025 adoption grew: first large integrations into Anthropic Claude Desktop, Cursor IDE, Continue, then Cloudflare, Block, Replit. Over 2025 and early 2026, OpenAI, Google and Microsoft announced official MCP adoption – OpenAI with support in the Agents SDK (March 2025), Google with the Vertex AI / Gemini tool-use bridge (late 2025), Microsoft with GitHub Copilot and Azure AI Studio (2025-2026). As of May 2026 MCP is the broadly accepted standard.
In May 2026 over 500 public MCP servers exist (see modelcontextprotocol.io/servers and GitHub registries like awesome-mcp-servers). Examples: filesystem server (read/write access to local files), GitHub server (repos, issues, PRs), Postgres server (DB queries with schema introspection), Slack server (channels, DMs, search), Google Drive server, Notion server, Linear server, Kubernetes server, Sentry server, Datadog server. Plus thousands of internal, non-public servers inside corporate environments.
Why it is a turning point
Before MCP, tool use was a provider-specific problem. Whoever built a tool for Claude had to build it separately for GPT – and a third time for Gemini. Switching providers meant rebuilding all integrations. Equipping multiple applications with the same tools meant copying integration code. Three consequences.
First: lock-in was strong. A fiduciary system that had implemented tool use with Claude could not easily switch to GPT-4 – even if GPT-4 became better at a certain task. The integration layer had to be rewritten.
Second: innovation in the tool world was slow. Whoever built a new tool (e.g. a Bexio connector for LLMs) had to maintain a separate adapter per provider. Open-source tools emerged more slowly than the actual demand grew.
Third: data-source connection was code-heavy. A simple Postgres connection to an agent required 100-300 lines of code per provider, with its own error handling, auth and schema modelling.
MCP solves all three. An MCP server (e.g. a Postgres MCP server) is built once and then used by every MCP-capable model and application. Switching from Claude to GPT? Change provider config; tools stay. Building a new tool for the entire ecosystem? One MCP server that works from day one in Claude, GPT, Gemini and all MCP clients.
For an SME this means in practice: invest in MCP servers, not provider-specific adapters. An MCP server for your internal client DB is a one-time investment (typically CHF 1500-6000 for SME complexity), immediately usable in every tool – Claude Desktop, Cursor, your own agent pipelines, future tools. Without MCP you would have needed a separate integration per tool.
Technology in detail
MCP defines three concepts and one transport protocol.
Resources. A data source an MCP server provides – e.g. a specific file, a client record, a Postgres schema. The model can query the list of available resources and read individual ones. Resources are read-only.
Tools. A function the model can call – e.g. "search_documents(query)", "send_email(to, subject, body)", "create_invoice(client_id, amount)". Tools have input schemas (JSON Schema) and return structured outputs. Tools can have side effects.
Prompts. Predefined prompt templates an MCP server provides – e.g. "summarise_meeting", "draft_reply". These are optional and less central than resources and tools as of May 2026.
Transport. MCP uses JSON-RPC 2.0 over two possible transports: stdio (server runs as a subprocess of the client, simple for local servers) or SSE/HTTP (server is a web service, good for remote/cloud servers). In May 2026 both are used in production; stdio for desktop apps and local tools, HTTP for cloud MCP servers.
Practical flow. A client (Claude Desktop, Cursor, your own agent pipeline) connects on startup to one or more MCP servers. The client asks each server: which resources, tools, prompts do you have? The server returns a catalogue. The client translates this catalogue into the native tool-use format of the LLM provider (Anthropic format, OpenAI format, ...). When the model calls a tool, the client sends the call to the matching MCP server, receives the result, returns it to the model. To the model it looks like a normal tool call. To the server developer it is a generic protocol, not a provider-specific API.
Open-source servers. As of May 2026 MCP SDKs exist in TypeScript, Python, Go, Rust, Java. Building a simple MCP server (e.g. for your own API) with the TypeScript SDK takes 30-90 minutes. Complex servers (e.g. with DB schema introspection and auth) take 1-3 days. The official server list (modelcontextprotocol.io/servers) grows weekly in May 2026.
MCP introduction in 5 steps
- 01Identify the use case: which data source or service should be accessible for how many tools/apps? If only 1 tool and 1 provider, MCP may be unnecessary.
- 02Check the server inventory: is there already an official MCP server (modelcontextprotocol.io/servers) for this data source? If yes, plug it in instead of rebuilding.
- 03Decide server architecture: local stdio server (runs as subprocess, simple, secure) or remote HTTP server (multiple clients, cloud deployment, needs own auth).
- 04Build the server with the MCP SDK (TypeScript or Python): define resources and tools with JSON Schema, pick auth, write eval tests. Typically 30 min to 3 days depending on complexity.
- 05Connect clients: configure in Claude Desktop, Cursor, your agent pipeline. Pin versions, log MCP calls, monitor.
When to use MCP
In May 2026 MCP is the right choice in five constellations.
First: you use multiple LLM providers. Once you run Claude AND GPT (or Gemini, Mistral, local Ollama) in parallel, MCP servers save double or triple integration work. A Postgres connection via MCP is immediately available in all MCP-capable clients.
Second: you use desktop tools like Claude Desktop, Cursor, Continue. These clients have MCP built in. If you want your own database, your own files or your own services accessible to Claude in the desktop app, MCP is the way – without MCP it simply does not work.
Third: you want to build a long-term tool catalogue. An SME building a growing library of internal tools over 12-24 months (Bexio connector, client DB server, internal document search, AML check service) should build them as MCP servers. The library grows additively without having to be rewritten per provider.
Fourth: you want to use third-party tools. As of May 2026 there are public MCP servers for Slack, GitHub, Google Drive, Notion, Linear, Sentry etc. Plug in instead of rebuilding – typically 5-30 minutes per server for config and auth.
Fifth: you want multi-tenant separation. An MCP server can expose different resources/tools per client context. Cleaner than filtering in provider-specific tool code.
Example application. A fiduciary builds an MCP server with three tools – `search_bexio`, `lookup_client`, `draft_invoice`. This server is used in parallel by Claude Desktop (for internal employee research), a custom client chat app with GPT-4 (for client self-service), and a batch script with Mistral-EU (for nightly bulk processing). Three apps, three models, one server.
When MCP is too much
Three cases where MCP produces overhead without benefit.
First: single app, single provider, single tool. If you build a small application with Claude and a single Bexio call, the native Anthropic tool-use call is the simplest route. Introducing MCP adds a layer without gain.
Second: latency-critical applications. MCP adds 5-50 ms per tool call (JSON-RPC roundtrip via stdio or HTTP). For typical chat apps irrelevant. For real-time voice agents or very tight inference loops it can be felt.
Third: security-critical tools with own auth logic. MCP servers have their own auth models (local stdio servers trust the client; HTTP servers need OAuth/API keys). For very sensitive tools (e.g. payment orders) it is sometimes cleaner to keep auth logic directly in the application instead of mediating through an MCP layer. May 2026 MCP auth patterns are expanding rapidly, but every new server brings auth-config complexity.
Security trap. Whoever connects remote MCP servers (HTTP MCP) potentially grants that server access to their LLM conversation data. For confidential applications (client data, professional secrecy SCC 321) never use a third-party MCP server for sensitive resources without that provider being under a data-processing agreement. Local stdio servers are safer because they run under your own control.
Maturity note. MCP is stable in May 2026 but younger than HTTP. Spec versions are still evolving (major versions Nov 2024, March 2025, Sep 2025, March 2026); server implementations vary in test coverage. For production: vet the server source, build your own eval suite, pin the version.
Trade-offs
STRENGTHS
- One tool – many models and apps, no provider lock-in
- 500+ public servers reduce own-build effort for standard integrations
- Server library grows additively – investments stay valuable
- Clean separation between plumbing layer (MCP) and intelligence layer (LLM)
WEAKNESSES
- Extra layer between app and model – 5-50 ms latency per tool call
- Young protocol – version-jump risk in the next 12 months
- Auth models for remote HTTP MCP are maturing – handle sensitive apps carefully
- Third-party MCP servers need DPA review, otherwise revFADP risk
FAQ
Does MCP solve the tool-use problem completely?
It solves the standardisation question between providers and tools. It does NOT solve the question of when an agent acts reliably – that remains a model and prompt question. MCP is the plumbing layer; the intelligence layer remains in the LLM. So "we introduced MCP" does not give you a reliable agent system – it gives you a maintainable tool inventory.
Which programming languages are supported?
In May 2026 official SDKs in TypeScript/JavaScript, Python, Go, Rust, Java/Kotlin and C#. Community SDKs in Ruby, PHP, Elixir, Swift. For SME builds we recommend TypeScript (largest example library) or Python (often the choice when the server also does LLM work). The choice is usually driven by the language of the existing service code the MCP server will couple to.
How do I secure an MCP server for client data?
Four layers. (1) Transport: local stdio (no network) or TLS + auth on HTTP. (2) Auth: API key or OAuth per client; per-tenant scoping. (3) Audit log: every tool request with caller ID, resource, tool, input/output, timestamp in a central audit DB (see ai-audit-trail-design). (4) Data protection: check whether the MCP client (e.g. Claude Desktop, Cursor) sends data to the LLM provider – the tool-call result ALWAYS enters the LLM context, hence also reaches the provider. For highly sensitive data use local Ollama or Mistral-EU as the model.