When Anthropic published the Model Context Protocol specification in late 2024, I bookmarked it with the mental note "worth watching." By early 2025, I was building with it. By mid-2025, MCP had become the infrastructure backbone of my entire content automation pipeline. In 2026, it's the most important AI integration standard you're probably underusing.
This post is an honest account of what MCP is, how it actually works, where it falls short, and what the adoption trajectory looks like for engineering teams serious about integrating AI into real systems — not demos, not proofs of concept, but production workflows that run every day without babysitting.
1. Why MCP Exists: The Problem It Solves
Before MCP, every AI integration was a custom engineering project. You wanted Claude to query your Salesforce CRM? Write a custom tool handler. You wanted it to search your GitHub repos? Another custom tool. You wanted it to look up Jira tickets, send Slack messages, and query your data warehouse — multiply that work by the number of integrations, and then multiply again for every AI provider you wanted to support.
The deeper problem wasn't just the volume of work. It was that every custom integration was bespoke and non-transferable. An integration built for Claude's function calling syntax couldn't be reused with OpenAI's tool spec or Google's Gemini API. AI providers had different schemas, different invocation patterns, different response formats. Building on any one of them created vendor lock-in at the integration layer.
MCP addresses this by standardizing the interface between AI models and external tools/data sources. Instead of writing a Claude-specific Salesforce integration and an OpenAI-specific Salesforce integration, you write one Salesforce MCP server. Any MCP-compatible AI host can use it. The integration work is done once.
That's the theoretical pitch. The practical reality in 2026 is more nuanced, but the core value proposition holds: MCP has established enough ecosystem momentum that the "write once, use everywhere" promise is increasingly real.
2. MCP Architecture: Host, Client, Server
MCP defines three roles in every interaction:
The MCP Host
The host is the AI application that an end user interacts with — Claude Desktop, a custom chatbot, an IDE plugin, or an automated agent pipeline. The host is responsible for presenting the conversation interface, managing the AI model lifecycle, and orchestrating MCP client connections. One host can maintain connections to multiple MCP servers simultaneously.
The MCP Client
The client lives inside the host. Each MCP client maintains a 1:1 connection with exactly one MCP server. The client is responsible for the protocol mechanics: establishing the connection, exchanging capability negotiations (what the server offers, what the client supports), and routing tool calls and responses. In Claude Desktop, for example, you configure multiple MCP servers in a JSON config file, and Claude Desktop spins up an MCP client for each one.
The MCP Server
The server is where the actual work happens. An MCP server exposes one or more of three primitives:
- Tools: Functions the AI can call (like a search API, a database query, a write operation). The AI decides when to call them based on context.
- Resources: Data that the AI can read (files, database records, API responses). Resources are fetched when requested; they don't get pushed to the AI automatically.
- Prompts: Pre-defined prompt templates that users or the host application can invoke to structure an interaction.
The server declares its capabilities during the initialization handshake. The host then knows what tools and resources are available without needing any out-of-band configuration.
Transport Layers
MCP supports two transport mechanisms. stdio transport is used for local servers: the host spawns the MCP server as a child process and communicates over standard input/output. This is simple, secure (no network exposure), and the default for local tool servers. HTTP with Server-Sent Events (SSE) is used for remote servers: the client connects to an HTTP endpoint and receives streamed responses over SSE. This is necessary for multi-user deployments where you can't run a separate server process per user.
One of the most anticipated changes on the 2026 MCP roadmap is the transition from SSE to Streamable HTTP — a simpler, more reliable transport that replaces SSE with a request/response model that also supports streaming. Streamable HTTP is already available in recent MCP spec versions and is the direction the ecosystem is moving.
3. MCP vs. Function Calling vs. Plugins: What's Actually Different
| Dimension | Function Calling | ChatGPT Plugins | MCP |
|---|---|---|---|
| Scope | Single-session, per-provider | OpenAI-specific | Cross-provider standard |
| Integration locus | In the API call payload | Plugin manifest + OpenAPI spec | Persistent server process |
| State across turns | No (stateless) | Limited | Server can maintain state |
| Data primitives | Tools only | Tools + limited retrieval | Tools + Resources + Prompts |
| Reusability | Provider-specific code | OpenAI only | Works with any MCP host |
| Deployment | Inline in client code | Hosted HTTP service | Local process or remote server |
| Auth standard | Provider-specific | OAuth (OpenAI-managed) | OAuth 2.0 (spec, not yet universal) |
| Community ecosystem | N/A (code pattern) | Deprecated (2024) | 300+ servers (growing fast) |
The most important practical difference between function calling and MCP: function calling is a mechanism within an API call. You pass a list of available functions in your API request, the model outputs a function call in its response, and your code executes it. Every conversation is stateless from the integration layer's perspective.
MCP is a protocol for a persistent relationship between an AI host and a tool server. The server is a running process. It can maintain connection state, cache data, subscribe to external event streams, and expose dynamic resource lists that update over time. This isn't something function calling can do, and it matters enormously for certain classes of integrations.
4. Implementing an MCP Server: TypeScript and Python
Anthropic provides official SDKs for building MCP servers in TypeScript and Python. Here's a representative structure for both (these are illustrative rather than copy-paste-production-ready).
TypeScript MCP Server Pattern
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
const server = new Server(
{ name: "my-data-server", version: "1.0.0" },
{ capabilities: { tools: {}, resources: {} } }
);
// Register a tool
server.setRequestHandler(ListToolsRequestSchema, async () => ({
tools: [{
name: "query_database",
description: "Run a read-only SQL query against the analytics database",
inputSchema: {
type: "object",
properties: { sql: { type: "string", description: "SQL query to execute" } },
required: ["sql"]
}
}]
}));
server.setRequestHandler(CallToolRequestSchema, async (request) => {
if (request.params.name === "query_database") {
const { sql } = request.params.arguments;
// Execute query, return results
const results = await runReadOnlyQuery(sql);
return { content: [{ type: "text", text: JSON.stringify(results) }] };
}
});
const transport = new StdioServerTransport();
await server.connect(transport);Python MCP Server Pattern
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
app = Server("my-data-server")
@app.list_tools()
async def list_tools():
return [
Tool(
name="search_knowledge_base",
description="Search the internal knowledge base for relevant documents",
inputSchema={
"type": "object",
"properties": {
"query": {"type": "string"},
"max_results": {"type": "integer", "default": 5}
},
"required": ["query"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict):
if name == "search_knowledge_base":
results = await search_kb(arguments["query"], arguments.get("max_results", 5))
return [TextContent(type="text", text=format_results(results))]
async with stdio_server() as (read_stream, write_stream):
await app.run(read_stream, write_stream, app.create_initialization_options())The pattern is the same regardless of language: register a server with capabilities, handle list requests (what tools/resources do you offer?) and invocation requests (execute this tool with these arguments). The SDK handles all the protocol mechanics: JSON-RPC message framing, capability negotiation, error handling.
5. Enterprise MCP: Real Use Cases
The use cases where I've seen MCP add genuine value in enterprise settings:
Slack Integration
A Slack MCP server lets Claude search message history, post messages, create channels, and look up user information. This is qualitatively different from just pasting Slack content into a chat window — the model can autonomously retrieve context from relevant channels, post summaries, and follow up on threads as part of a larger automated workflow. We use this in our weekly reporting pipeline: Claude pulls data from three sources, drafts a summary, and posts it to the leadership channel with zero manual intervention.
GitHub Integration
The official GitHub MCP server exposes repository operations: searching code, reading file contents, creating pull requests, managing issues. Combined with Claude's code understanding, this enables workflows like: "review open PRs in this repo that have been waiting more than 48 hours, summarize the changes, and add a comment asking the author if they need review assistance." That's a 20-line workflow, not a custom application.
SAP and Enterprise ERP
This is where MCP starts getting genuinely interesting. SAP has an MCP server (in partner preview as of early 2026) that exposes read access to core business objects: customers, orders, invoices, purchase orders. The practical use case: a procurement analyst asks Claude "show me all open POs for this supplier that are past due and calculate the total exposure." Without MCP, that's a BI report that someone builds in advance. With MCP, it's a conversational query against live data. The analyst doesn't need to know the SAP table structure or run a transaction.
Salesforce CRM
Similar pattern to SAP. The Salesforce MCP server exposes SOQL queries, record reads and writes, and report execution. Sales teams use it to build automated daily briefings: before each customer call, Claude pulls the account history, recent opportunities, open cases, and last three email threads — and formats a prep document. The account executive didn't write a single line of code. The MCP server did the integration work once.
6. MCP Security Considerations
MCP's power is also its attack surface. The security considerations are real and worth thinking through carefully before deploying MCP servers in production.
Tool Poisoning
Tool poisoning is the MCP-specific variant of prompt injection. A malicious actor crafts content — in a document, a database record, a web page — that includes instructions designed to hijack the AI's behavior when the model reads it via an MCP tool. Example: a support ticket in your ticketing system contains hidden text that, when read by an AI agent processing tickets, instructs the AI to exfiltrate other ticket content or take unauthorized actions.
Mitigations: treat all data returned by MCP tools as untrusted input. Implement human-in-the-loop checkpoints for high-privilege actions (anything that writes data, sends messages, or modifies state). Use output parsers that strip control sequences from tool results before they re-enter the model context.
Callout: The Confused Deputy Problem in MCP
MCP servers often have elevated permissions — they're running as a privileged process that can access databases, APIs, and file systems. When a user (or attacker) tricks the AI into calling an MCP tool in an unintended way, the MCP server executes with its full permissions, not the user's permissions. This "confused deputy" pattern is the most serious security risk in MCP deployments. Design MCP servers to be the least privileged they can be for their intended use case. Read-only servers are significantly safer than read/write servers.
Permission Scope
MCP servers should implement their own authorization layer — don't assume that because the AI can call a tool, the user asking the AI should have access to the underlying resource. An enterprise MCP server that exposes HR data should check the requesting user's identity and permissions before returning sensitive records. As of 2026, MCP's OAuth 2.0 support is formalizing how user identity flows through from the host to the server, but many existing servers don't implement this correctly. Verify before you deploy.
Server Registration Trust
In Claude Desktop (and similar hosts), users can add arbitrary MCP servers via config files. A malicious MCP server can return crafted tool descriptions that manipulate the model. Some hosts are implementing "MCP server signing" — requiring servers to present certificates before being loaded. This is nascent but worth watching.
7. Claude Extended Thinking + MCP
Claude's extended thinking mode (where the model is given a token budget to reason through a problem before producing an answer) pairs particularly well with MCP tool use. Without extended thinking, multi-step tool workflows tend to be linear: call a tool, get a result, call the next tool. With extended thinking, Claude can reason through what information it needs, plan a sequence of tool calls, anticipate what the results will tell it, and adjust its plan before executing.
In practice, this shows up most clearly in research-style tasks. I ran an experiment where I asked the same question about a company's financial position to Claude with and without extended thinking, with access to the same set of MCP tools (a web search server, a data query server, and a document retrieval server). Without extended thinking, Claude made four sequential tool calls, getting incrementally more data. With extended thinking (budget: 10,000 tokens), Claude's thinking trace showed it planning all six tool calls upfront, reasoning about what each would contribute, and identifying a dependency — one query needed the result of another before it could be formed. The final answer with extended thinking was demonstrably more complete and better-structured.
The practical guidance: use extended thinking for agentic MCP workflows where the number of required tool calls isn't known in advance, or where tool call planning requires complex reasoning. For simple, predictable tool sequences (call this API, format the result, present it), extended thinking adds latency without proportional benefit.
8. Multi-Agent Systems and MCP
One of the most significant architectural shifts MCP enables is making multi-agent systems practical. In a multi-agent system, you have multiple AI instances coordinating to complete a task. Each agent may have access to different tools and different context. The orchestrator agent routes subtasks to specialist agents.
Before MCP, each agent in a multi-agent system needed its own bespoke tool implementations. With MCP, agents share tool servers. An orchestrator agent and a specialist agent can both connect to the same GitHub MCP server and the same database MCP server. The tool implementation is written once; both agents benefit.
The emerging pattern I'm seeing in production multi-agent systems:
- An orchestrator agent with broad tool access (read everything, coordinate everything)
- Specialist agents with narrow tool access (the code review agent only has access to GitHub; the customer research agent only has access to CRM and support tickets)
- All agents share a "memory" MCP server that provides persistent context storage across agent turns
- A "human handoff" tool that any agent can call when it needs human review before proceeding
9. MCP Ecosystem in 2026
The MCP server ecosystem has grown faster than I expected. Some notable servers available as of 2026:
Official/reference servers (maintained by Anthropic or MCP community): filesystem, fetch (web content), memory (key-value persistence), git, GitHub, GitLab, Google Drive, Slack, Postgres, SQLite, Puppeteer (web automation), Brave Search.
Enterprise integrations: Salesforce, SAP, Jira, Confluence, ServiceNow, Datadog, PagerDuty, Snowflake, dbt, Tableau, Notion.
Developer tools: AWS (multiple services), GCP, Azure, Kubernetes, Terraform, Docker, Vercel, Railway, Cloudflare.
Specialized: Linear, Figma, Stripe, Twilio, SendGrid, various financial data providers.
Aggregator directories like MCP.so and the official Anthropic MCP server registry list over 1,000 servers (varying quality). The signal/noise ratio is improving as more organizations publish officially maintained servers rather than personal projects.
Callout: Evaluating MCP Server Quality
Before using a community MCP server in production, check four things: (1) Is it actively maintained? Look at commit history. (2) Does it implement proper error handling? A server that crashes or hangs on unexpected input will break your entire AI workflow. (3) Does it have rate limiting and retry logic for external API calls? (4) Does it handle sensitive data (credentials, PII) correctly — is it logging anything it shouldn't? The best servers are the ones that work invisibly; you only notice them when they don't.
10. Local vs. Remote MCP Servers
The choice between local (stdio) and remote (HTTP/SSE or Streamable HTTP) MCP servers has significant operational implications.
Local stdio servers are simpler and more secure. The server process runs on the same machine as the host. No network exposure, no authentication needed between client and server (they're on the same machine), and no latency overhead beyond local IPC. The limitation: they don't scale to multiple concurrent users, and they require the server code to be installed on every user's machine. Right for: personal productivity workflows, developer tools, single-user Claude Desktop configurations.
Remote HTTP servers are needed for organizational deployments. One server instance serves multiple users. Access control can be enforced centrally. The server can connect to internal systems without requiring every user's laptop to have VPN or credentials. The trade-off: you need HTTPS, authentication (OAuth 2.0 is the target standard, though support varies), and more robust error handling for network failures.
In my organization, we run a fleet of internal MCP servers behind an API gateway. The gateway handles authentication (validating JWT tokens from our SSO system), rate limiting (per-user and per-server), and request logging for compliance. Individual MCP servers don't implement any of this — they trust the gateway's authentication header and focus on their specific capability. This pattern dramatically simplifies building new MCP servers: you implement the tool logic, the gateway handles everything else.
11. MCP's Current Limitations
I want to be direct about what MCP doesn't do well yet, because I've seen adoption decisions made based on inflated expectations.
No Stateful Conversations by Default
Despite MCP servers being persistent processes, the protocol itself is stateless at the session level in most implementations. Each tool call is independent. If you want an MCP server to remember context across multiple calls within a conversation, you have to build that yourself — either by maintaining session state in the server keyed on a session ID, or by using a dedicated memory server. The "memory" primitive in MCP Resources helps but isn't automatic.
Authentication Standards Are Still Maturing
OAuth 2.0 support is specified in the MCP spec but inconsistently implemented. Many servers expect API keys in environment variables. When you're deploying MCP servers for an organization with 500 users who all need different permission levels, the authentication story today requires custom implementation work. The Streamable HTTP spec includes a more complete OAuth 2.0 integration, and this should improve significantly through 2026.
Debugging Is Hard
When something goes wrong in an MCP tool chain, diagnosing it is painful. The host shows you the AI's outputs. The AI shows you its tool calls. But what the server actually received, what it sent to the external API, and why it returned an error — that requires server-side logging that you have to build yourself. Anthropic's MCP Inspector is helpful for development, but production observability tooling for MCP workflows is still immature.
Context Window Pressure
Every MCP tool result consumes context window tokens. In complex workflows with many tool calls, the context can fill with tool results faster than expected. Managing context window usage in MCP-heavy workflows requires either summarizing tool results before injecting them into context, or carefully designing workflows to minimize redundant tool calls. This isn't a MCP-specific problem, but it's one that MCP's ease-of-use can obscure until you hit a production token limit.
12. 2026 MCP Roadmap
Based on Anthropic's published roadmap and the MCP community's GitHub discussions, here are the developments to watch in 2026:
Streamable HTTP transport is replacing SSE as the primary remote transport. It's simpler (no persistent SSE connection management), more reliable (standard HTTP semantics), and supports streaming responses via the same request. Expect most major MCP servers to migrate by end of 2026.
OAuth 2.0 standardization — the MCP spec is formalizing OAuth 2.0 flows for both user-delegated authentication and machine-to-machine service authentication. This will make enterprise deployments significantly simpler and close the biggest security gap in the current ecosystem.
Server-to-server communication — MCP currently defines client-server relationships, but multi-agent architectures need servers to communicate with each other. The spec group is working on server-to-server interaction patterns that would let an MCP server call other MCP servers as part of a tool execution.
Richer resource types — current Resources are essentially file-like blobs. The roadmap includes structured data resources with schema information, enabling hosts to make smarter decisions about how to inject resource content into context.
13. MCP vs. REST API vs. GraphQL for AI Integration
| Dimension | MCP | REST API | GraphQL |
|---|---|---|---|
| AI-native design | Yes — built for model tool use | No — designed for HTTP clients | No — designed for frontend clients |
| Discovery | Built-in (capability negotiation) | OpenAPI spec (separate) | Introspection query |
| Schema for tools | JSON Schema per tool | OpenAPI (if present) | SDL type system |
| Streaming | Native (Streamable HTTP) | SSE or WebSocket (add-on) | Subscriptions (WebSocket) |
| Integration effort | Low (SDK-based) | Medium (write tool handlers) | Medium (query builder needed) |
| Reuse across AI hosts | Yes (any MCP host) | No (re-wrap per provider) | No (re-wrap per provider) |
14. Key Takeaways
- MCP solves the N×M integration problem. Instead of building N integrations for M AI providers, you build N MCP servers that work with all MCP-compatible hosts. The ecosystem network effect grows over time: every server you build or adopt works with Claude, Cursor, Claude Desktop, and any other MCP-compatible host.
- The Host/Client/Server architecture is well-designed but adds operational complexity. You're running persistent server processes now, not just making API calls. Plan for server lifecycle management, health monitoring, and restart handling.
- Security requires deliberate design, not afterthought. Tool poisoning, confused deputy vulnerabilities, and improper permission scoping are real risks. Design MCP servers with minimum necessary permissions and treat all tool-returned data as untrusted.
- Extended Thinking + MCP is a meaningful quality improvement for complex agentic workflows. The planning capability pays off when the number of required tool calls isn't predetermined.
- Local stdio servers for personal productivity; remote HTTP servers for organizational deployment. The operational requirements are different enough that choosing the wrong deployment model causes significant friction.
- The current limitations — statelessness, immature auth, debugging difficulty — are known and being addressed. The Streamable HTTP and OAuth 2.0 additions on the roadmap directly address the two most painful production pain points. Adopt now if your use case tolerates the current limitations; monitor the roadmap if you can't.
I use MCP internally to connect Claude to my content pipeline — See how it works
댓글
댓글 쓰기