67. Model Context Protocol (MCP) Explained: The “USB‑C” for AI Tools (and the Safety Checklist That Matters)

Last Updated: May 31, 2026

The Model Context Protocol (MCP) has crossed the threshold that distinguishes a promising open standard from actual infrastructure. Anthropic reported 97 million monthly SDK downloads in March 2026 — a growth trajectory from 100,000 to 97 million in 18 months that the React npm package took approximately three years to achieve. The official MCP Registry contained 9,652 server records as of a May 24, 2026 API pull. GitHub shows 15,926 repositories tagged with the mcp-server topic. Every major AI platform — Anthropic, OpenAI, Google DeepMind, Microsoft, Salesforce, GitHub, Amazon — has committed to MCP support. In December 2025, Anthropic donated the protocol to the Agentic AI Foundation, a directed fund within the Linux Foundation co-founded by Anthropic, Block, and OpenAI with support from Google, Microsoft, AWS, and Cloudflare — making MCP vendor-neutral, community-governed infrastructure rather than a single company’s product.

Understanding MCP matters in 2026 for a reason that goes beyond the adoption numbers: it solves a problem that every team building AI agents eventually hits. When you want an AI application to query your database, read files from your file system, send a Slack message, and check a GitHub issue, you traditionally write a custom integration for each one — tightly coupled to both the specific AI model’s API format and the external tool’s unique interface. The N×M problem. With MCP, you build each tool integration once as an MCP server and any conforming MCP client — Claude, ChatGPT, Cursor, VS Code, or your own application — can use it without modification. The integration tax that made multi-tool agent deployments expensive and fragile is significantly reduced. The MCP specification is open, the SDKs are free, and the server ecosystem covers the tools your team most likely needs.

This upgraded guide covers MCP comprehensively for 2026. You will find a plain-English architecture explanation with the three primitives and two transports that define the protocol, the full adoption timeline with milestones and platform coverage, a beginner-friendly step-by-step setup guide with a working Python code example, the five security risks that the OWASP MCP Top 10 and security research have identified as most critical, and a comparison table positioning MCP against REST APIs and function calling. For the agentic AI context that MCP enables, our guide to autonomous AI agents covers how MCP fits into the broader agentic architecture. For the security-first deep-dive, our dedicated guide to MCP security for beginners covers hardening, authentication, and incident response for MCP deployments in full depth.

1. 🤔 What Is MCP? The Architecture in Plain English

The Model Context Protocol is an open standard — built on JSON-RPC 2.0 — that defines how AI models communicate with external tools, databases, and services. Think of it as USB-C for AI: a single standard connector that lets any compliant device talk to any other, without writing custom adapters for every combination. Before MCP, connecting Claude to your Postgres database required a different integration than connecting GPT-4 to the same database. After MCP, you build one Postgres MCP server and every conforming AI client can use it identically.

MCP uses a client-server architecture with three roles. The Host is the AI application the user interacts with — Claude Desktop, Cursor, VS Code, or your own application. The Client is the component inside the host that speaks MCP — it discovers and communicates with servers on behalf of the AI model. The Server is the component that wraps an external tool or data source and exposes it through MCP — a Postgres server that knows SQL, a GitHub server that knows the GitHub API, a filesystem server that can read and write files.

MCP servers expose three types of capability — called primitives. Tools are functions the AI can call — analogous to POST endpoints in a REST API. A tool might send an email, run a database query, or create a GitHub issue. Resources are read-only data sources the AI can access — analogous to GET endpoints. A resource might be the content of a file, the schema of a database, or the output of a report. Prompts are reusable prompt templates that guide the AI through specific workflows — analogous to pre-built workflows or runbooks. The host communicates with servers using one of two transport mechanisms: stdio (standard input/output) for local processes running on the same machine as the host, and Streamable HTTP (the 2026 production standard, replacing the earlier SSE-based HTTP transport) for remote servers accessed over the network. Both transports use the same JSON-RPC 2.0 message format, so tool definitions are fully portable between local development and remote production deployments.

Why MCP Matters for AI Agents Specifically

Single-turn AI interactions — asking a question and getting an answer — do not particularly benefit from MCP. The protocol’s value compounds dramatically in agentic workflows, where an AI system needs to take multiple sequential actions across multiple systems to complete a complex task. Without MCP, an agent that needs to check a calendar, read a Slack thread, look up a customer record, and file a support ticket needs four custom integrations, each maintained separately, each potentially breaking when the AI model API changes. With MCP, those four tools are four MCP servers — and the agent host handles all the discovery, invocation, and result routing through a single standardized protocol layer. Cloudflare demonstrated this concretely: by using MCP to let agents discover and call tools dynamically rather than loading all tool definitions upfront, they achieved 98%+ token savings — because the agent only loads tool definitions for the tools it actually needs rather than the full catalog.

2. 📊 MCP Adoption Status: Who Is Using It in 2026?

MCP’s adoption timeline is one of the fastest protocol adoption stories in enterprise software history — faster than REST’s broad adoption, faster than OAuth’s uptake, and comparable to the speed at which the Language Server Protocol conquered IDE integrations after Microsoft’s initial implementation. The measured adoption data as of May 2026 — drawn from the official MCP Registry API, GitHub repository counts, and primary vendor announcements — tells a consistent story: MCP has crossed from developer experiment to industry infrastructure.

The adoption timeline moves in clear phases. November 2024: Anthropic releases MCP as an open-source protocol alongside reference servers for GitHub, Slack, Google Drive, Postgres, and Puppeteer. Initial adoption is limited to Claude Desktop and early adopters. March 2025: OpenAI officially adopts MCP across its products, including the ChatGPT desktop application. This is the critical inflection point — when the second major AI provider commits, the protocol stops being one vendor’s standard and becomes an industry standard. September 2025: OpenAI adds MCP support to ChatGPT apps, enabling third-party tool access inside ChatGPT. December 2025: Anthropic donates MCP to the Linux Foundation’s Agentic AI Foundation (AAIF), co-founded with Block and OpenAI, with Google, Microsoft, AWS, and Cloudflare as supporting organizations. MCP officially becomes vendor-neutral, community-governed infrastructure. The MCP specification adds asynchronous operations, statelessness, server identity, and official extensions. January 2026: MCP Apps launches, extending the protocol into interactive user interfaces — tools can now return rich HTML interfaces rendering in sandboxed iframes within the AI conversation. Launch partners include Amplitude, Asana, Box, Canva, Clay, Figma, Hex, monday.com, Slack, and Salesforce. March 2026: Anthropic reports 97 million monthly SDK downloads. April 2026: AAIF holds the MCP Dev Summit North America in New York City, drawing approximately 1,200 attendees — the first major in-person community event for the MCP ecosystem. May 2026: Official MCP Registry API records 9,652 server entries; GitHub shows 15,926 repositories tagged with mcp-server; the modelcontextprotocol/servers repository reaches 86,148 stars and 10,799 forks.

The MCP adoption signal that matters most: Cross-provider commitment is what turns a protocol into infrastructure. MCP crossed that threshold in March 2025 when OpenAI committed to support. Infrastructure standards only become infrastructure when all major players adopt them — prior to that, they are just one of several competing approaches. The five-vendor founding of the AAIF (Anthropic, Block, OpenAI with Google, Microsoft, AWS, Cloudflare supporting) confirmed that MCP is not Anthropic’s protocol. It is the industry’s protocol.

Who Supports MCP in 2026: The Complete Platform Map

The client side of MCP adoption — the AI applications and tools that can connect to MCP servers — has reached near-complete coverage among the tools that developers and enterprise AI teams use daily. WorkOS’s 2026 MCP ecosystem analysis identifies the confirmed client-side adopters as: Claude (full support in Claude Desktop, Claude API, and Claude Code — Anthropic maintains the reference implementation); ChatGPT (desktop app and Assistants API tool framework — GPT-4 and o-series models use MCP servers as function calling tools); Gemini (Google AI Studio and Vertex AI agents — Gemini 3.1 models support MCP through the Google AI Agent framework); Microsoft Copilot (Copilot Studio and Semantic Kernel — Azure OpenAI integration); GitHub Copilot (MCP support for codebase context); Cursor (deep MCP integration for AI development context); VS Code (native MCP client in the GitHub Copilot extension); Windsurf (AI development environment with MCP); and Zed (editor with MCP client support). On the server side, the official and community-maintained MCP servers now cover: Slack, GitHub, Google Drive, Postgres, SQLite, Notion, Linear, Sentry, Figma, Webflow, Cloudflare, Stripe, HubSpot, Shopify, Postman, WooCommerce, WordPress, Salesforce, and hundreds more. The MCP Registry categorizes servers across productivity tools, developer infrastructure, data platforms, communication tools, and search and retrieval systems — with the developer tools category showing the strongest early adoption.

3. 🛠️ Getting Started with MCP: Step-by-Step for Beginners

The fastest path to understanding MCP is building a simple server — the hands-on experience of exposing a tool through MCP and then calling it from Claude Desktop or another MCP client makes the architecture concrete in a way that reading a specification cannot. The guide below assumes basic Python knowledge (familiarity with functions and pip install) and nothing else. If you prefer TypeScript, the official MCP SDK is available for both languages with equivalent APIs. SDKs also exist for Java, Kotlin, C#, Go, Rust, and Swift — all accessible from the official MCP GitHub organization.

Step 1: Install the MCP Python SDK

Open your terminal and install the official MCP Python package:

Terminal:
pip install mcp

If you prefer using uv (the fast Python package manager that Anthropic’s own examples use):
uv add mcp

Step 2: Write Your First MCP Server

Create a file called weather_server.py. This example builds a simple server that exposes one tool — a weather lookup — and one resource — the list of supported cities. This is enough to demonstrate all the core MCP concepts without external API dependencies:

weather_server.py:
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp import types

app = Server("weather-server")

# Define a tool: get_weather
@app.list_tools()
async def list_tools() -> list[types.Tool]:
    return [types.Tool(
        name="get_weather",
        description="Get current weather for a city. Returns temperature and conditions.",
        inputSchema={"type": "object", "properties": {
            "city": {"type": "string", "description": "City name"}},
            "required": ["city"]})
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_weather":
        city = arguments["city"]
        # In production: call a real weather API here
        return [types.TextContent(
            type="text",
            text=f"Weather in {city}: 22°C, partly cloudy"
        )]

if __name__ == "__main__":
    import asyncio
    asyncio.run(stdio_server(app))

Step 3: Test with MCP Inspector

Before connecting your server to an AI host, test it in isolation using the MCP Inspector — a standalone developer tool that lets you interactively explore what your server exposes, call its tools, and inspect the responses. Run it with Node.js via npx:

Terminal:
npx @modelcontextprotocol/inspector python weather_server.py

This opens an interactive UI in your browser where you can call get_weather directly and verify the response before connecting the server to any AI host. This step is the most important quality gate in MCP development: verify in the Inspector first, then connect to a real AI client. Never skip this step for servers that will access sensitive data or take real-world actions.

Step 4: Connect to Claude Desktop

To make your server available to Claude Desktop, add it to Claude’s configuration file. On macOS, this file lives at ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows, it is at %APPDATA%\Claude\claude_desktop_config.json:

claude_desktop_config.json:
{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["/path/to/your/weather_server.py"]
    }
  }
}

Restart Claude Desktop. In a new conversation, Claude will now have access to your weather server’s tools. Type: “What’s the weather in London?” and Claude will call your get_weather tool automatically.

Step 5: Find Community Servers Before Building Your Own

Before writing custom MCP servers for common tools, check the MCP Registry at modelcontextprotocol.io — the official catalog maintained by the community. Postgres, SQLite, GitHub, Slack, Google Drive, Notion, Linear, Sentry, and hundreds of other common integrations already have well-tested, community-maintained servers available. The official modelcontextprotocol/servers GitHub repository is the best starting point for vetted reference servers. For productivity tools, developer infrastructure, and SaaS platforms, the integration work for most business applications is already done. Building a custom server is the right choice for your organization’s proprietary internal tools, private data sources, and custom business logic — not for wrapping publicly available services that already have community servers.

4. ⚖️ MCP vs REST API vs Function Calling: When to Use Each

One of the most common sources of confusion about MCP is how it relates to the two alternatives developers already know: REST APIs and function calling. They are not competitors — they operate at different layers of the stack and serve different purposes. Understanding where each one belongs is the prerequisite for making the right architecture decision for any specific AI application.

The practical decision rule for 2026: if you are building a tool integration that you want to use from more than one AI application, or that you want to work with multiple AI providers, build an MCP server. If you are building a quick one-off integration for a single application with a single AI provider, function calling is faster to set up and sufficient. If the underlying service has an existing REST API and an existing community MCP server, use the community server rather than reinventing the wheel. Our guide to function calling and tool use covers the model API layer in depth — the complement to MCP’s integration layer.

5. 🔒 MCP Security: What You Need to Know Before Deploying

MCP’s power comes from the same source as its security risk: it gives AI agents direct, standardized access to real systems that can take real actions. An AI agent with an MCP server for your database can query, insert, and delete data. An agent with an MCP server for your email can read and send messages. An agent with an MCP server for your file system can read, write, and delete files. The same capability that makes MCP transformative for agentic AI makes it a significant attack surface if deployed without appropriate security controls. Security researchers at Palo Alto Networks’ Unit 42, the OWASP Foundation, and academic research teams have identified and documented the specific attack patterns that MCP deployments face in 2026.

The five most critical MCP security risks — drawn from the OWASP MCP Top 10, TrueFoundry’s enterprise security analysis, and published academic research — are the foundation for any responsible MCP deployment checklist.

Risk 1: Prompt Injection Through External Data

Prompt injection is the highest-severity risk in MCP environments because it exploits the fundamental trust relationship between AI agents and the content they process. An attacker embeds hidden instructions in external data that an MCP server retrieves — a GitHub issue, a document in a watched folder, a database record, a webpage the agent browses. When the AI agent reads that data, it may interpret the embedded instructions as legitimate commands and execute them using its own permissions. The impact compounds because MCP agents have real system access: a successful prompt injection that causes an agent to read a malicious GitHub issue and then use its connected credentials to pull private repository data is not theoretical — Invariant Labs documented this exact attack pattern against the official GitHub MCP server in 2025. The MCP specification itself acknowledges the risk directly, stating that there SHOULD always be a human in the loop with the ability to deny tool invocations. Security researcher Simon Willison, who has tracked prompt injection since 2022, wrote that “we still don’t have convincing mitigations” — making defense-in-depth the only practical current approach.

Risk 2: Tool Poisoning and Rug Pull Attacks

Tool poisoning exploits the trust that AI agents place in tool metadata. When an agent connects to an MCP server, it requests a list of available tools via the tools/list command. The server responds with tool names and descriptions that are added to the model’s context. The agent uses that metadata to decide which tools to invoke. The security vulnerability is that these tool descriptions can contain hidden instructions that the AI model sees but users reviewing the configuration do not. An attacker who controls an MCP server — or who compromises a legitimate server through supply chain attack — can embed malicious directives in tool metadata. Rug pull attacks are the temporal variant: a tool that initially appears legitimate becomes malicious after gaining user trust. Once users approve a tool connection, new sessions inherit the updated (poisoned) tool definition without re-triggering consent flows. The OWASP MCP Top 10 explicitly lists tool poisoning, schema poisoning, and tool shadowing as distinct sub-techniques under this attack category.

Risk 3: Over-Privileged Agent Access and Credential Sprawl

Over-permissioning is one of the fastest ways MCP integrations go wrong. When MCP servers are configured with broader permissions than the specific task requires — database read-write access when only read is needed, full repository access when only a specific branch is needed, organization-wide scope when only a single workspace is needed — the blast radius of any compromise or mistaken instruction expands to the full scope of those permissions. This problem compounds as organizations deploy multiple MCP servers: credentials accumulate across servers, scopes that were appropriate for a pilot never get tightened for production, and the aggregate permission surface of the agent grows beyond what any individual reviewer has explicitly approved. The MCP specification’s 2026 update introduced incremental scope consent, allowing clients to request only the minimum access needed for each operation rather than requesting all permissions upfront — but implementing this requires an authorization layer that understands tool-level semantics, not just network-level routing.

Risk 4: Audit Blind Spots and Missing Observability

Traditional API gateways cannot read agent intent. An AI agent task that triggers tool calls to 20 different MCP servers generates traffic that, at the network level, appears as a sequence of legitimate, authenticated requests. Nothing in the HTTP envelope reveals whether those requests are the result of legitimate user intent or a successful prompt injection. This is the audit blind spot that characterizes most current MCP deployments: security teams can see that a request was made, but cannot reconstruct whether it was intentional, whether it was triggered by malicious content, or which sequence of agent reasoning produced it. Enterprise observability for MCP deployments requires immutable audit logs of every tool invocation correlated with the agent context that triggered it — a capability that most organizations deploying MCP in 2026 are building from scratch, without standardized tooling support.

Risk 5: Shadow MCP Servers and Supply Chain Risk

The openness that makes MCP’s ecosystem grow fast — anyone can publish an MCP server, the registry has no mandatory security vetting, and installing a community server requires only a few lines of configuration — creates a shadow IT and supply chain risk analogous to the npm package ecosystem. The OWASP MCP Top 10 defines “Shadow MCP Servers” as unapproved or unsupervised MCP instances operating outside formal security governance. Developers who want a specific tool integration will install community MCP servers without IT security review. Those servers may contain malicious code, pull in vulnerable dependencies, or be rug-pulled after establishing trust. The SitePoint guidance is direct: “Read the code before connecting it to a host with credentials.” The practical mitigation is a maintained allow-list of approved MCP servers for organizational use — equivalent to a vetted npm registry or approved container image catalog — with a formal review process for adding new servers. Our dedicated guide to MCP Security for Beginners covers the complete hardening checklist, OAuth 2.1 authentication implementation, and incident response procedures for MCP deployments in full depth.

The five MCP security controls that must be in place before any production deployment: (1) Least-privilege credentials for every MCP server — scope to the minimum access the specific task requires, use short-lived tokens, rotate regularly. (2) Human approval gates for destructive or irreversible actions — database deletions, external data transfers, financial transactions, bulk modifications. (3) An allow-list of approved servers — only servers that have been security-reviewed may be connected to organizational hosts. (4) Immutable audit logging for every tool invocation with agent context. (5) Regular review of active server permissions — scopes granted during pilots that were never tightened become the attack surface exploited in production.

6. 🔮 MCP in 2026: What’s Coming Next

The 2026 MCP roadmap, published by the AAIF maintainers and analyzed by The New Stack in March 2026, identifies four priority areas that will define MCP’s evolution through Q4 2026: enterprise authentication, multi-agent coordination, governance maturation, and enterprise readiness. Enterprise authentication focuses on OAuth 2.1 with PKCE for browser-based agents and SAML/OIDC integration for enterprise identity providers including Okta and Azure AD — unlocking regulated industry deployments that require enterprise-grade authentication currently absent from most MCP deployments. Multi-agent coordination is the most architecturally significant roadmap item: using MCP as the coordination protocol for agent-to-agent communication, where one agent calls another as if it were a tool server. This enables hierarchical agent architectures where orchestrator agents delegate to specialized sub-agents through MCP — and it is where the convergence with Google’s Agent-to-Agent (A2A) protocol is most visible. The two protocols address adjacent problems: MCP handles model-to-tool communication, A2A handles agent-to-agent communication, and the ecosystem is beginning to converge on using both together.

The broader commercial trajectory is visible in the server ecosystem: cloud providers are beginning to build hosted MCP server marketplaces, positioning MCP as infrastructure rather than just a protocol. Cloudflare’s Workers platform supports MCP server deployment natively. AWS is building MCP support into its agent tooling. Vercel’s platform includes MCP deployment capabilities. The same hosting and managed service model that transformed REST APIs from something developers built from scratch into something they subscribe to is beginning to apply to MCP servers — which will significantly lower the deployment barrier for organizations without dedicated AI engineering resources and accelerate the adoption timeline the current data already shows.

7. 🏁 Conclusion: MCP Is Now the Default Assumption for AI Agent Integration

The combination of 97 million monthly SDK downloads, cross-vendor adoption by every major AI platform, Linux Foundation governance, 9,652+ official registry entries, and a developer ecosystem of 15,926+ GitHub repositories represents something specific and important: MCP has crossed the threshold from “interesting protocol to evaluate” to “default assumption for AI agent integration.” The SurePrompts framing captures it precisely: “MCP support is increasingly a checkbox feature for AI applications because the cost of not supporting it outpaces the cost of supporting it.” This is the same dynamic that drove broad Language Server Protocol adoption after Microsoft’s initial VS Code implementation — once the protocol is cheap to implement and the ecosystem benefits are large, not supporting it becomes the unusual choice.

The practical implication for developers and organizations building AI applications in 2026 is straightforward: if your AI application needs to connect to external tools and data sources, start with MCP. Check the community registry for servers that cover your needed integrations before building custom ones. Build any proprietary integrations as MCP servers so they are portable across AI clients and providers. And invest in the security controls covered in Section 5 before those servers go anywhere near production data or systems — because the same openness that built MCP’s ecosystem fast also created attack surfaces that require explicit governance to manage. The protocol is ready for production. The security infrastructure to deploy it responsibly requires intentional investment that the 97 million download figure suggests most deployers have not yet made.

📌 Key Takeaways

🔗 Related Articles

• 📖 MCP Security for Beginners (2026): How Model Context Protocol Can Be Exploited + a Hardening Checklist
• 📖 Function Calling and Tool Use Explained: How AI Chatbots Actually “Do” Things
• 📖 Autonomous AI Agents Explained: How Agentic AI Plans, Acts, and Completes Tasks
• 📖 Non-Human Identity (NHI) for AI Agents: How to Prevent Privilege Abuse and Rogue Actions
• 📖 Multi-Agent Systems Explained: How Multiple AI Agents Coordinate and How to Keep Them Safe