Model Context Protocol (MCP)

The Model Context Protocol, introduced by Anthropic in late 2024 and now adopted across the ecosystem, is the closest thing the LLM world has to a USB-C plug for tools and data. Instead of every assistant building bespoke integrations to every data source, MCP defines a common protocol for exposing context — files, search results, business data, actions — to any MCP-aware model client.

Why It Exists

Before MCP, the integration story for any model client looked like:

• Each assistant builds its own integration to GitHub, Slack, Google Drive, Linear, your database, your wiki.
• Each new tool or model client multiplied the work — N tools × M clients = a quadratic mess.
• Tool builders had to maintain separate adapters for ChatGPT plugins, Claude Desktop, Cursor, Continue, Zed, and so on.

MCP collapses this to N + M: tools expose an MCP server; clients speak MCP. Any client can talk to any server.

The Architecture

Three roles:

• MCP server. Wraps a data source or tool. Exposes capabilities.
• MCP client. Lives inside an LLM-using application; speaks MCP to one or more servers.
• Host. The model-facing application — Claude Desktop, an IDE, a custom agent — that orchestrates everything.

Servers and clients communicate over a JSON-RPC-based protocol, typically over stdio (for local processes) or HTTP/SSE (for remote services).

What Servers Expose

Three primitives:

• Tools. Functions the model can call. Just like provider-native function calling, but discoverable through the protocol.
• Resources. Read-only context the model can pull in — files, database rows, API responses.
• Prompts. Reusable prompt templates that the host can offer as commands or slash-options.

A server can expose any combination. A GitHub server might expose tools (create_issue, merge_pr), resources (file contents, PR diffs), and prompts (review_pr, summarize_changes).

Why It Matters in Practice

• Plug-in ecosystems. Open-source servers exist for hundreds of common tools — databases, file systems, web search, email, calendars, design tools, dev tools. Plug in, no code.
• Local-first integrations. Servers can run locally with full filesystem and credential access, without sending sensitive data through a third-party platform.
• Transferable workflows. A workflow built around MCP servers works across any MCP-aware client. Your tool inventory comes with you.
• Custom servers in hours. A small custom MCP server is a couple of hundred lines in any language with an SDK; teams ship them quickly.

When to Build a Server vs Use Existing

• Existing servers for common SaaS, dev tools, databases, files: just configure them.
• Custom servers when you have proprietary internal data or actions worth wrapping: build one, share it across your team's tooling.
• Don't build a server for a one-off integration in a single application — direct API calls are simpler.

Security Considerations

MCP servers run with whatever permissions you give them. That's powerful and dangerous:

• Untrusted servers can be vehicles for prompt injection, data exfiltration, or worse. Treat third-party MCP servers like any other unaudited dependency.
• Local server credentials should be scoped — read-only when possible, narrow OAuth scopes, separate keys.
• Tool authorization still matters. Just because a server exposes a delete_database tool doesn't mean every model invocation should be allowed to call it.
• Auditing. Log every tool call from every MCP-connected agent. Indirect prompt injection through resources is a real attack surface.

Limitations Today

The protocol is young and evolving:

• Discovery. Finding good servers still mostly happens through curated lists rather than a built-in registry.
• Authentication. Auth flows for remote servers are improving but not yet uniform.
• Streaming. Real-time streaming of resources is supported but not always well.
• Version compatibility. Server and client versions can drift; expect occasional incompatibilities.
• Spec surface. New primitives (sampling, roots, elicitation) keep being added; older clients may not support them.

Most of these are normal early-protocol issues; they're being addressed.

Adoption

Adopters as of 2025:

• Anthropic. Native in Claude Desktop, Claude Code, Claude API.
• OpenAI. Native MCP support in their consumer and developer products.
• IDE clients. Cursor, Continue, Zed, Cline, Windsurf, JetBrains AI.
• Tooling layers. LangChain, Mastra, Vercel AI SDK, Pydantic AI all have MCP integrations.
• Hundreds of community servers. Including official ones from GitHub, Atlassian, Stripe, Cloudflare, Notion, Figma, and major cloud providers.

The momentum is real; "speaks MCP" is becoming a default feature of new model clients.

What to Watch

• MCP for agents — emerging primitives for sub-agent invocation, not just tools.
• MCP registry — a directory and trust model for discoverable servers.
• Standard auth — OAuth and similar flows formalizing across servers.
• Competing protocols — Google's A2A, agent2agent, others. Whether they converge with MCP or stay distinct is open.

For most teams building today, MCP is already the right default for any non-trivial tool integration.