← Power User Path

MCP: What It Is and Why It Matters

A technical deep dive into the Model Context Protocol: how it works mechanically, why the ecosystem is growing so fast, when to install vs. build, and where it's still rough around the edges.

advanced 25 min read Updated Mar 2026
YOUR PROGRESS
6 of 7 ← Prev Next →

MCP: What It Is and Why It Matters

If you’ve been paying any attention to the AI tooling space over the past year, you’ve heard about MCP. You’ve probably seen it mentioned in Claude Desktop settings, in GitHub READMEs, in developer newsletters. What you may not have is a solid mental model for what it actually does, how it works at a mechanical level, and whether it’s worth your time.

This article gives you that mental model. It’s aimed at developers and technical power users who want to understand MCP properly, not just hear that it exists.

If you just want a practical introduction to setting up MCP with Claude Desktop, start with the No-Code Automation article instead. That covers the quickstart. This article goes deeper.

What You’ll Learn Here

  • The actual problem MCP was built to solve, and the math that makes it compelling
  • How the protocol works mechanically: transports, components, and the flow of a real tool call
  • What tools, resources, and prompts are, and why the distinction matters
  • What the ecosystem looks like and where to find servers
  • How to decide whether to install a pre-built server or build your own, with code examples for both
  • Real workflow examples that show what this looks like in practice
  • Where MCP is genuinely rough around the edges, including documented security incidents
  • Where the protocol is heading

The Protocol That Ate the AI Tool Problem

Before MCP, connecting AI to external tools was an N times M problem.

If you had N AI applications and M tools or data sources, you needed N times M custom integrations. Every AI product built its own plugin system, its own API wrapper, its own integration layer. ChatGPT had its own plugin format (since deprecated). Cursor had its own context-loading system. Claude had its own API integration approach. None of them interoperated. If you built a Jira integration for Cursor and then switched to Claude Code, you started over.

For a company managing internal AI tooling, this was a serious tax: a new AI product meant new integrations. An API change in one tool could break multiple places at once. Maintenance was constant.

MCP collapses that to N plus M. Instead of every AI building its own bridge to every tool, you have one protocol. N AI hosts each build one MCP client. M tools each build one MCP server. Any host can talk to any server. The integrations are portable and composable.

MCP (Model Context Protocol) was released by Anthropic in November 2024. By early 2026, it has become the standard way AI applications connect to external tools and data sources. Every major AI platform now supports it: Claude, ChatGPT, Gemini, GitHub Copilot, VS Code, Cursor, and more. Over 10,000 servers exist in the ecosystem. SDK downloads are running above 97 million per month. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, with Anthropic, OpenAI, Google, Microsoft, and AWS among the governing members.

That backstory matters because it answers the first question a sensible engineer asks: is this another short-lived vendor initiative, or does it stick? The governance move and cross-vendor adoption answer it. This is infrastructure now, not a trend.

Part 1: What MCP Actually Is

1.1 The Problem: AI That Can Only Talk

LLMs are text in, text out. They don’t have inherent connections to your files, databases, APIs, or services. Someone has to bridge that gap. Before MCP, every AI application built its own bridge, and those bridges didn’t work with any other AI application.

Concrete examples of what that looked like:

  • If you wanted Cursor to have access to your Jira tickets, you needed a Cursor-specific Jira integration. Switching to Claude Code meant rebuilding it.
  • A company running three different AI tools for different teams maintained separate integrations for each tool’s access to the same internal systems.
  • An open source contributor building a GitHub integration had to choose which AI products to target. There was no “build it once, works everywhere.”

The pre-USB analogy holds. Before USB, peripheral manufacturers built separate connectors for every computer manufacturer. USB standardized the physical and logical interface. Any device, any port. MCP does the same thing for AI tool integrations.

1.2 The Protocol: What It Actually Does

MCP is a communication protocol, not a framework, library, or product. It specifies how an AI application and an external tool should talk to each other.

Under the hood: MCP is built on JSON-RPC 2.0, a lightweight remote procedure call standard that encodes requests and responses as JSON. The transport layer supports two modes:

Stdio (standard input/output): For local servers running on the same machine. The host application spawns the server as a subprocess and communicates with it via stdin and stdout. Simple, fast, minimal overhead. This is how most desktop MCP integrations work.

Streamable HTTP: For remote servers. The host sends HTTP POST requests; the server can stream responses back using Server-Sent Events. This is how hosted, production MCP servers work. The November 2025 spec added Streamable HTTP as the canonical remote transport, replacing the earlier HTTP+SSE approach.

Both transports speak the same protocol. Server logic written for stdio can be adapted to HTTP without changes.

The design was inspired by LSP (Language Server Protocol), which solved an analogous problem for code editors. Before LSP, every IDE had to build its own Python language support, its own TypeScript language support, and so on. LSP standardized the interface: Python tools expose an LSP server, any compatible editor connects to it. MCP applies the same pattern to AI tool integrations.

1.3 The Three Core Components: Host, Client, Server

This is the architecture you need to internalize before anything else clicks.

The Host

The host is the user-facing application that contains or calls the AI model. Claude Desktop is a host. Claude Code is a host. Cursor is a host. VS Code with Copilot is a host. Any application you’re building that wraps an LLM is a host.

The host is responsible for managing the conversation with the user, running or calling the LLM, deciding when to invoke tools based on the model’s output, and creating and managing MCP clients.

The Client

The client lives inside the host. It’s the component responsible for talking to a specific MCP server. One client per server, always. If your host connects to three servers (GitHub, Postgres, Slack), there are three clients running inside it.

The client handles establishing and maintaining the connection to its server, capability negotiation (the handshake where client and server agree on which features they both support), and translating the host’s requests into MCP protocol messages and back.

Most developers never write a client from scratch. Client logic is built into the MCP SDK, and the host application handles it. If you’re building a host, you’ll use the SDK’s client code. If you’re building a server, you mostly don’t think about clients at all.

The Server

The MCP server is the bridge to an external tool or data source. It’s a separate process, local or remote, that exposes specific capabilities to any connected host. The GitHub MCP server speaks MCP on one side and the GitHub API on the other. The Postgres server speaks MCP on one side and SQL on the other.

The server is responsible for exposing its capabilities (what it can do and what data it provides), responding to requests from clients, and doing the actual work: making API calls, reading files, querying databases, running commands.

Servers are the part of the ecosystem you’ll most commonly install. If you’re a developer building an integration, they’re also what you’ll build.

Concrete walkthrough: what happens during a tool call

A developer has Claude Desktop connected to a GitHub MCP server. They ask: “Create a new branch called feature-auth and open a draft PR with this description.”

  1. Claude (the LLM inside Claude Desktop) processes the request and determines it needs to invoke a GitHub tool
  2. The host directs its GitHub client to send a tool invocation request to the GitHub server
  3. The GitHub server receives the request, calls the GitHub API, creates the branch and draft PR
  4. The server sends the result back to the client
  5. The client relays it to the host
  6. The host incorporates the result into Claude’s context
  7. Claude generates a confirmation for the user

The user never saw JSON-RPC. They just had a conversation. That’s the point.

1.4 The Three Primitives: Tools, Resources, Prompts

MCP servers expose three types of capabilities. Understanding the distinction is important for debugging and for building.

Tools are executable functions. They do things: query a database, call an API, write a file, send a message. Tools can have side effects. The LLM chooses which tools to call based on what the user wants. Tool invocations typically require approval from the user or host. Think of tools as verbs.

Resources are data sources. They expose content for reading: documents, database records, configuration files, anything that provides context. Resources don’t take actions; they describe things. The application, not the model, decides when to fetch resources and include them in context. Think of resources as nouns.

Prompts are reusable message templates the server exposes to the client. Pre-written instruction patterns that guide the model toward consistent behavior for common tasks. Users or client applications trigger prompts explicitly; they don’t run automatically. Think of prompts as reusable scripts.

Why this distinction matters when debugging: if something is a tool, it gets called on-demand by the model, can fail, needs permissions, and has side effects. If it’s a resource, it gets fetched by the client and is mostly passive. If it’s a prompt, it’s user-initiated and deterministic.

Three less-common primitives worth knowing:

Sampling lets the server ask the client to run an LLM completion. The server says “I need the model to summarize this text, please do the completion and return the result.” This keeps the LLM call inside the client’s security boundary rather than the server making its own independent API call. Useful for server-side processing that needs model intelligence without the server managing its own LLM credentials.

Roots let the client tell the server which filesystem paths it can access. Prevents servers from reading outside their designated scope. A file system server with roots set to ~/Documents/project can’t go looking through ~/Desktop.

Elicitation, added in the June 2025 spec update, lets the server ask the client to collect additional information from the user mid-interaction. Enables interactive workflows where the server doesn’t have everything it needs upfront and needs to ask follow-up questions rather than failing.

Part 2: Why MCP Is a Meaningful Shift

2.1 Before MCP: The Integration Tax

To make this concrete, consider what it looked like to build an internal AI assistant in early 2024.

You wanted it to read from Confluence, query your Postgres database, and post to Slack. What that meant:

  • Write a Confluence API wrapper and handle OAuth
  • Write a Postgres connection layer with connection pooling and query safety
  • Write a Slack API wrapper with proper webhook or bot token handling
  • Wire all of it into your specific LLM framework (LangChain, LlamaIndex, or custom)
  • Maintain all of it when any of those APIs changed
  • Rebuild everything if you wanted to switch LLMs

That’s weeks of work before the assistant does anything useful for users. And when your team started using a second AI product, you started again. That integration tax was real, and teams paid it constantly.

2.2 After MCP: One Protocol, Composable, Portable

With MCP, each of those integrations is a server. The Confluence API wrapper is a Confluence MCP server. Someone writes it once, publishes it, and anyone using any MCP-compatible host can install it. The Postgres connection is the Postgres MCP server.

The math changes. Instead of N AI hosts times M tools equaling N times M integrations, you get N hosts each building one MCP client, plus M tools each building one MCP server. N plus M instead of N times M.

More importantly, the integrations are portable. You build your workflow with Claude Desktop today. When you switch to a different MCP-compatible host next year, your server configurations move with you. No rebuilding. The investment compounds.

2.3 The Ecosystem Effect

The ecosystem has passed the threshold where it becomes self-sustaining. As of early 2026:

  • Every major AI platform supports MCP. OpenAI adopted MCP in March 2025, integrating it across the Agents SDK and Responses API. Google DeepMind confirmed Gemini support in April 2025. Microsoft integrated MCP into Azure OpenAI and Microsoft 365.
  • Over 10,000 servers exist in the ecosystem
  • Official SDKs in Python, TypeScript, C#, and Java
  • Monthly SDK downloads above 97 million
  • An official registry launched September 2025 and community directories listing thousands more

When this many vendors commit to the same protocol, it becomes infrastructure regardless of what any individual vendor does next. That’s what the Linux Foundation governance move was designed to signal: MCP is now a community asset, not an Anthropic product.

Part 3: The MCP Ecosystem

3.1 Finding Servers: Where to Look

Official Registry: The MCP registry, launched September 8, 2025, is the canonical discovery layer. Backed by Anthropic, GitHub, PulseMCP, and Microsoft. It stores metadata and points to packages on npm, PyPI, Docker Hub, or GitHub. Think of it as an app store index, not a package host. The API was frozen at a stable v0.1 as of October 24, 2025.

Anthropic’s reference servers: The reference server repository contains a curated set of reference implementations. These show correct implementation patterns and are useful for learning. They’re not trying to be a comprehensive catalog.

Community directories:

  • PulseMCP: Updated daily, over 8,600 servers listed as of early 2026. The most comprehensive catalog of what exists.
  • MCP Server Hub: Filterable by category, use case, and host compatibility.

The official registry has a curation process. Community directories do not. When you install from a community directory, treat it the same way you’d treat any random open-source package.

3.2 Key Servers Worth Knowing

Developer tools:

  • GitHub: Create branches, read repos, open PRs, search code, manage issues. One of the most-used servers in developer workflows.
  • GitLab: Same pattern for GitLab users.
  • Git (local): Read commit history, diffs, and branch state from local repos.
  • PostgreSQL and MySQL: Natural language queries to your databases. High value, high risk. Always set up a read-only user.
  • SQLite: Lighter-weight local database access.
  • Docker: Manage containers, inspect logs, run commands.
  • Kubernetes: Interact with clusters, inspect pods, manage deployments.

Google Workspace:

  • Google Drive: Read, search, and reference documents.
  • Gmail: Read and send email, search threads.
  • Google Calendar: Read events, check availability.
  • Google Docs and Sheets: Read and modify documents directly.

Productivity and project management:

  • Slack: Read channels, post messages, search history.
  • Notion: Read pages and databases, create and update content.
  • Asana, Linear, Jira: Read and create tasks, manage projects.

Data and infrastructure:

  • AWS (S3, EC2, RDS, and more): Manage AWS resources. Microsoft also ships an Azure MCP server.
  • Cloudflare: Manage workers, KV storage, DNS.
  • BigQuery and Snowflake: Query data warehouses.
  • Chroma and Pinecone: Vector database search for embeddings-based retrieval.

Browser and web:

  • Playwright and Puppeteer: Programmatic browser automation. Powerful but requires a browser process.
  • Fetch and web search: Basic HTTP requests and search capabilities.

Local and memory:

  • Filesystem: Read, write, and traverse your local file system. One of the most useful for power users; one of the highest-risk if granted broad permissions.
  • Memory: Persistent memory server that lets the LLM store and recall facts across sessions.

Specialty:

  • Blender: Control Blender’s 3D scene from natural language.
  • Microsoft ships servers for Azure DevOps, Microsoft 365 (Graph API), Teams, and several other products.

3.3 A Note on Quality and Trust

The existence of 10,000+ servers does not mean 10,000 servers are trustworthy or production-ready. Many are weekend projects. Some are excellent. A few are actively malicious, which the security section covers in detail.

Practical heuristics when evaluating a community server:

  • Check when the repository was last updated. Dormant repos may have known unpatched issues.
  • Look at what permissions the server requests. A weather server asking for filesystem access is a red flag.
  • Prefer servers from established vendors (Microsoft, Atlassian, GitHub, Cloudflare) for sensitive integrations.
  • Read the source code if the server touches sensitive data. Most servers are 200-500 lines of TypeScript or Python. It’s not a large ask.

Part 4: Building vs. Using

4.1 When to Install an Existing Server

Most people should start here. Install a pre-built server, configure it, see if the integration is useful, and invest engineering time only once you know it is.

Install rather than build when:

  • A well-maintained server exists for the tool you need to connect
  • The server is from a trusted source
  • Your use case is fairly standard (reading files, querying databases, posting messages)
  • You want to evaluate whether MCP is worth your time before committing engineering resources

Getting started is genuinely not complicated. Configuration is a JSON object with the server’s name, the command to run it, and any environment variables (usually API keys). Most server documentation includes a ready-to-paste config block.

Claude Desktop: Settings > Extensions, or manually edit claude_desktop_config.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your_token_here"
      }
    }
  }
}

VS Code: Settings > MCP Servers (pulls from the GitHub registry by default).

Cursor: Add server configuration to .cursor/mcp.json in the same format.

4.2 When to Build Your Own

Build when:

  • No server exists for the internal system or tool you need to connect
  • You need custom logic that existing servers don’t support (custom filtering, auth, data transformation)
  • You’re building a product where other developers or users will connect AI to your API
  • You want to expose an existing API as an MCP server so it’s usable by AI tools in the ecosystem

What building actually involves:

The official MCP documentation covers building a server in detail. Both the Python and TypeScript SDKs are solid. Choose based on your existing stack.

Minimum viable server in Python, using the FastMCP wrapper:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-server")

@mcp.tool()
def get_customer(customer_id: str) -> dict:
    """Fetch customer record from our internal API."""
    return internal_api.get_customer(customer_id)

if __name__ == "__main__":
    mcp.run()

TypeScript equivalent (see the FreeCodeCamp TypeScript handbook for a full walkthrough):

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "my-server", version: "1.0.0" });

server.tool(
  "get_customer",
  { customer_id: z.string() },
  async ({ customer_id }) => {
    const customer = await internalApi.getCustomer(customer_id);
    return { content: [{ type: "text", text: JSON.stringify(customer) }] };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

The development process:

  1. Install the SDK (pip install mcp or npm install @modelcontextprotocol/sdk)
  2. Define your tools, resources, and any prompts
  3. Test locally with the MCP Inspector: npx @modelcontextprotocol/inspector
  4. Configure your host application to run the server
  5. Deploy to a cloud host (Cloudflare Workers, Fly.io, Vercel, AWS) for remote access

Critical gotcha for stdio servers: Never write to stdout with print() or console.log(). Stdio servers communicate via stdout, so anything you write there corrupts the protocol stream. Use stderr for logging, always.

How long does it take? A simple server wrapping an existing API is a day of work or less. A production-ready server with auth, error handling, rate limiting, and deployment is a few days. The SDK handles the protocol; most of your code is business logic.

Frameworks worth knowing:

  • FastMCP (Python): Higher-level abstraction on top of the official Python SDK. Less boilerplate for common patterns.
  • fastapi_mcp: Zero-config bridge that turns any existing FastAPI app into an MCP server. If you already have a FastAPI service, this is the fastest path.
  • Gradio: Set mcp_server=True when launching to expose any Python function as an MCP tool instantly. Great for ML demos and quick experiments.

Part 5: MCP in Practice

5.1 Developer Workflow: Code Review Assistant

Setup: Claude Code (host) + GitHub MCP server + Linear MCP server + local filesystem server.

Workflow: The developer asks Claude to look at their assigned open PRs, find any that haven’t been updated in more than three days, and draft a comment asking the author for an update.

  1. GitHub server fetches assigned PRs and their activity timestamps
  2. Claude filters for stale PRs, drafts appropriate follow-up comments
  3. Developer reviews the drafts and approves
  4. GitHub server posts the comments

The value is not that Claude is smarter than a developer. It’s that the mechanical work (scan list, filter by date, compose a routine message) is handled automatically. The developer spends time on reviews, not on tracking which reviews need nudging.

5.2 Engineering Team: QA to Tickets

From a deployment at Gradient Labs: engineers used Notion (for test results), Claude Code, and the Linear MCP server to automate QA ticket creation.

  1. Testers add rows to a Notion database with test results and feedback
  2. Claude reads the Notion database via MCP
  3. Claude categorizes and deduplicates issues, groups related problems by underlying cause
  4. Linear MCP creates a new project with properly structured tickets

What took hours of organizing and writing took minutes. The key was Claude applying judgment about what constitutes the same underlying issue, not just a mechanical data transformation.

5.3 Data Analyst: Natural Language Database Queries

Setup: Claude Desktop + Postgres MCP server connected to a read-only analytics replica.

Rather than writing SQL for every ad-hoc question, the analyst asks: “What was month-over-month active user growth by cohort for Q4?” Claude generates and runs the query, formats the results, and explains what it found.

Always use a read-only database user for this pattern. The Postgres MCP server can execute arbitrary SQL. Give it only the permissions it needs.

5.4 Operations: Cross-Tool Information Gathering

Setup: Claude Desktop + Gmail, Google Drive, Slack, Notion MCP servers.

Request: “Look at the Slack messages from the #client-acme channel this week, find the emails from that client in my Gmail, and create a Notion page summarizing the current project status and outstanding items.”

Claude coordinates across four tools, reads all the relevant data, synthesizes it, and creates structured output. This is where MCP genuinely shines: multi-tool information gathering that would require 30 minutes of manual context-switching takes a few minutes.

5.5 Content Creator: Automated Research Pipeline

Setup: Claude Desktop + web search server + GitHub (for a content repo) + local filesystem.

The writer asks: “Research current pricing for the top five CRM tools, check if our existing CRM article has that information, and give me a list of updates needed.”

Claude searches the web for current pricing, reads the existing article from the repo, compares them, and produces a specific list of changes. Research that would take an hour is done in minutes.

Part 6: Current Limitations and Rough Edges

MCP is genuinely useful. It also has real problems. Anyone making a serious decision about adopting it deserves an honest picture.

6.1 Security Is a Real Problem

This section covers documented incidents, not theoretical risks.

Prompt injection and tool poisoning: MCP servers provide tool descriptions that the LLM reads during capability negotiation. A malicious server can embed instructions in those descriptions. The LLM reads what it thinks are tool usage guidelines, but actually reads instructions to exfiltrate data or take unauthorized actions.

This has been demonstrated in practice. Invariant Labs executed a tool poisoning attack in which a malicious MCP server silently exfiltrated a user’s WhatsApp history by hiding instructions in tool descriptions. Read the full account of documented MCP security incidents, including this attack and others.

The Authzed timeline of MCP security breaches is useful context on how quickly the attack surface has developed since MCP’s launch.

The rug pull attack: You install a legitimate server and approve it. The server operator later updates the tool definitions to include malicious instructions. Your one-time approval doesn’t protect you from what the server does after you approved it.

Supply chain attacks: In October 2025, CVE-2025-6514 was disclosed in mcp-remote, a popular OAuth proxy with 437,000+ downloads. A malicious server could send a crafted authorization_endpoint that executed arbitrary OS commands on the client machine. This is a real supply chain attack vector, not a hypothetical.

Additionally, CVE-2025-11445 in Kilo Code demonstrated that prompt injection via MCP could silently modify a user’s settings.json, changing AI behavior without the user’s knowledge.

Microsoft has published guidance on protecting against indirect injection attacks in MCP, which is worth reading if you’re deploying MCP in any enterprise context.

Practical mitigations:

  • Install servers only from sources you trust. Vendor-published servers from major companies (Microsoft, Atlassian, GitHub) are lower risk than anonymous community servers.
  • Read the source code for community servers that touch sensitive data. Most are 200-500 lines. It’s not a large ask.
  • Never grant a server more permissions than it needs. Read-only database user. Specific Drive folders, not “all of Drive.” Specific repos, not all repos.
  • Run servers in containers or sandboxed environments when possible.
  • Monitor server updates. A server that changed behavior after you approved it is a red flag.

What the November 2025 spec added: OAuth 2.1-based authorization and Resource Indicators (RFC 8707) to prevent token mis-redemption. These help, but only if server operators implement them correctly. Many don’t. The November 2025 spec is the current reference.

6.2 Context Window Constraints

When a host connects to many MCP servers, tool definitions consume context. Each server publishes its tools with descriptions and parameter schemas. A host connected to 20 servers with 10 tools each is consuming hundreds or thousands of tokens just on tool definitions before any actual work starts.

The practical guidance: don’t connect everything to everything. Connect the tools relevant to your current workflow. Context windows are large, but they’re not infinite, and crowding them with unused tool definitions degrades reasoning quality.

6.3 Async and Long-Running Operations

The November 2025 spec introduced a Tasks primitive to support long-running operations. Before that, MCP was fundamentally synchronous: the client sent a request, the server responded, done. That worked for API calls that return in a second or two. It broke down for operations that take minutes: running a full test suite, processing a large document, deploying a build.

The Tasks primitive allows servers to return a handle, publish progress updates, and deliver results asynchronously. But this is new as of late 2025. Most existing servers don’t use it yet. If your use case involves long-running operations, verify that the specific server supports Tasks before assuming it will work cleanly.

6.4 Server Quality Is Inconsistent

10,000+ servers sounds like a rich ecosystem. The quality distribution is not uniform. Many servers are:

  • Abandoned after initial release
  • Only tested against one specific version of one host application
  • Missing error handling for common failure modes
  • Poorly documented

Official vendor servers (Microsoft, GitHub, Atlassian, Cloudflare) are generally reliable. Community servers are variable. The ecosystem is maturing, but it is not mature.

6.5 Authentication Is Still Rough

Remote MCP servers need authentication. The June 2025 spec added OAuth 2.1 support. The November 2025 spec tightened it further. But in practice, many servers still use simple API key passing in environment variables or request headers. That works, but it’s not the auth story enterprise deployments need.

Enterprise concerns that aren’t fully solved yet:

  • Centralized management of which servers employees can install and run
  • Audit logs of what tools were called and with what parameters
  • Role-based access control for server capabilities
  • Governance registries that enforce approved-server policies

These are being actively worked on. If you’re evaluating MCP for enterprise deployment, verify that the auth and governance story meets your compliance requirements before committing.

6.6 Agent-to-Agent Communication Is Still Early

MCP handles host-to-server communication well. Agent-to-agent communication, where one AI agent calls another AI agent via MCP, is on the roadmap but not fully standardized. If you’re building multi-agent systems where agents need to delegate to subagents, expect spec ambiguities and rough edges.

Part 7: Where MCP Is Heading

7.1 Governance: The Linux Foundation Move

In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. Read Anthropic’s announcement and the Linux Foundation’s formation announcement for the full details.

The founding members: Anthropic, OpenAI, Block, Google, Microsoft, AWS, Cloudflare, Bloomberg, Cisco, IBM, Oracle, Salesforce, SAP, Snowflake, and Hugging Face. Individual projects, including MCP itself, retain full autonomy over technical direction. Strategic and governance decisions rest with the foundation.

What this means practically: MCP is no longer an Anthropic project. It’s neutral infrastructure. This eliminates the biggest enterprise adoption risk (single-vendor dependency) and puts MCP on the same footing as Kubernetes and Node.js: community-governed, vendor-neutral, and built to last.

7.2 Agent-to-Agent Communication

The current spec focuses on host-to-server communication. The next frontier is standardizing how AI agents communicate with each other. The 2026 roadmap vision is fractal agentic systems: a top-level agent breaks a task into sub-tasks, delegates to specialized subagents, each of which may further delegate, all coordinated through a common protocol.

Google has an adjacent project called Agent-to-Agent Protocol (A2A) that approaches this from a different angle. The relationship between MCP and A2A is still being worked out. There’s overlap, and the community is actively discussing which layer handles what. Do not treat the relationship as resolved; it isn’t.

7.3 Enterprise Governance Tooling

MCP adoption is currently heavy on the developer side and lighter on enterprise IT governance. As more organizations deploy agentic workflows, demand will grow for centralized control over which servers employees can run, audit trails of tool invocations and their parameters, and data loss prevention mechanisms that understand the MCP layer.

Vendors are building this. Expect it to be a significant piece of the enterprise AI infrastructure story in 2026 and 2027.

7.4 Semantic Tool Discovery

Currently, hosts discover tools by asking a server what it exposes and getting a flat list back. As the server ecosystem grows, a smarter approach is needed: semantic ranking that helps the model find the right tool for a task across a large ecosystem, rather than loading every tool definition into context upfront. This is on the roadmap and will matter significantly as the number of available tools grows.

7.5 MCP Becoming Invisible Infrastructure

The most accurate long-range prediction: MCP becomes something you don’t think about, in the same way you don’t think about TCP/IP or HTTP. The tools you use will support it; the integrations you need will exist; the protocol exchange will happen in the background.

Understanding MCP now gives you the vocabulary to reason about that infrastructure before it’s invisible. That’s when you need to understand it: before it’s everywhere.

Conclusion: What to Take Away

Three practical points:

If you’re using Claude or any major AI platform: You’re already in the MCP ecosystem. The connections in Claude Desktop’s Extensions section are MCP servers. You don’t need to understand the protocol to benefit from it, but knowing what it is helps you evaluate which servers are safe to install and which to avoid.

If you’re a developer building something AI-adjacent: Learn the basics of building MCP servers now. Every API you expose as an MCP server is immediately usable by every AI tool in the ecosystem. The return on that investment compounds as adoption grows.

If you’re making infrastructure decisions: MCP is not a trend to watch. It’s infrastructure to plan around. The Linux Foundation governance move and cross-vendor adoption have made this as stable a bet as any open standard gets.

Next steps: