MCP Protocol: How AI Agents Talk to the Outside World
The Cage Problem Here's something worth thinking about: why do AI assistants still feel "trapped," even when the underlying models are genuinely powerful? As…
The Cage Problem
Here's something worth thinking about: why do AI assistants still feel "trapped," even when the underlying models are genuinely powerful?
Ask one for today's stock price — it says it doesn't know, no live data. Ask it to scan your GitHub repo for security issues — it can't see the repo. Ask it to send an email — it drafts one for you and then... waits for you to do the actual sending.
The model capability isn't the bottleneck. Tool access is.
That's exactly what MCP — the Model Context Protocol — is built to fix.
MCP in One Sentence
MCP is an open protocol proposed by Anthropic in late 2024. Its job: standardize how AI agents connect to external tools.
Before MCP, every AI product that wanted to integrate a third-party tool had to build its own bridge: define the tool description format, handle auth, parse responses. Twenty products integrating the same tool meant twenty separate implementations. Wasteful and fragmented.
MCP's answer: standardize it. Tool providers implement an MCP Server. AI applications integrate an MCP Client. Both sides speak the same protocol — tool descriptions, call formats, response schemas, all unified.
Think of it like HTTP for the web. MCP wants to be HTTP for agent-tool communication.
Architecture: Three Roles
The MCP ecosystem has three players:
MCP Host: The AI application you're using — Claude Desktop, Cursor, OpenClaw. It runs the MCP Client, communicates with Servers, and exposes tool capabilities to the model.
MCP Server: The tool implementation. A single Server can expose multiple Tools, Resources, and Prompt templates. A GitHub MCP Server, for example, might expose "list PRs," "create issue," and "read file" as separate tools.
MCP Client: Embedded in the Host, handles the MCP protocol communication with Servers.
The communication runs over JSON-RPC 2.0, either via local stdio (for local processes) or remote HTTP+SSE (for cloud services):
AI Application (Host)
↓ MCP Client
├── Local Server A (stdio)
├── Local Server B (stdio)
└── Remote Server C (HTTP/SSE)Local Servers communicate through inter-process channels — near-zero latency. Remote Servers go over the network, suited for cloud-hosted services.
A Full Tool Call, Step by Step
Take "what's AAPL's price today?" as an example:
- User sends the message to the AI
- The LLM identifies this task needs real-time stock data and decides to call
get_stock_price - MCP Client sends a tool call request (JSON-RPC) to the connected Server
- The MCP Server (stock data service) executes the query and returns results
- Results get injected into the AI's context; the AI responds with real data
The whole thing is transparent to the user. It feels like talking to someone who actually knows the current price.
The key is step 2 — the model autonomously decides which tool to use. The user doesn't say "use the stock tool." The model identifies what capability the task requires and calls it. That's agent behavior, not just glorified autocomplete.
MCP vs. Function Calling
People often ask: doesn't OpenAI's Function Calling already let models use tools? What does MCP add?
Function Calling is a model-layer capability — it lets a model output structured tool invocation requests. But defining those tools, managing them, and executing them? Still left to each application to figure out.
MCP is an ecosystem-layer protocol. It doesn't replace Function Calling (MCP tool calls still go through Function Calling under the hood). What it solves is the higher-level problem: tool discovery, description, and lifecycle management.
Analogy: Function Calling is "you can make phone calls now." MCP is "the phone book + call protocol + carrier integration spec."
Three Capability Types: Tools, Resources, Prompts
An MCP Server can expose three things:
Tools: Executable functions with side effects — send email, query a database, call an API. The core capability.
Resources: Read-only data sources — file contents, database records, API responses. No side effects.
Prompts: Pre-defined prompt templates the Server provides. A code review Server might offer a "code-review" template with review criteria already baked in.
Combine all three and a Server can offer a fairly complete "domain service" — the domain's data, operations, and expert framing all in one package.
What's Available: The MCP Server Ecosystem
The MCP ecosystem grew quickly through 2025. By early 2026, commonly used open-source Servers include:
- Filesystem: Read/write local files, directory operations
- Databases (PostgreSQL / SQLite): SQL queries, schema inspection
- Code platforms (GitHub / GitLab): PR operations, issue management, code search
- Communication (Slack / Gmail): Send messages, read emails
- Search (Brave Search / Perplexity): Real-time web search
- Browser control (Playwright): Open pages, take screenshots, fill forms
- Memory systems: Persistent memory, knowledge graph queries
Anthropic maintains a set of reference implementations, and the third-party community is contributing fast. ClawHub already has 200+ MCP-related skill packages.
How We Use It at SFD Lab
SFD Lab runs 13 collaborating Agents, each with their own toolset. We've been migrating tool integration from hand-written function call schemas to MCP since last year.
A few things we noticed:
Tool reuse is much easier. Before, our backend Agent (小章鱼) and our full-stack Agent (小灰狼) both needed database access and had to maintain their own tool descriptions. Now they share a single PostgreSQL MCP Server — update once, both benefit.
Debugging is significantly better. MCP's JSON-RPC traffic is plaintext. When something fails, you read the log and immediately see what the Client sent and what the Server returned. Before, a failed tool call meant a long guessing game: was it the model's call format? The tool implementation? The schema mismatch?
Gotcha we hit: Local stdio Servers need careful process management. If a Server crashes, the Host won't auto-reconnect — you need manual restart or a health check script. Once our GitHub MCP Server for 小猎鹰 (security audit Agent) silently died. Two consecutive audit tasks failed and we spent nearly 30 minutes before realizing it was just a dead process.
Security: What You Need to Know
MCP's convenience comes with real security considerations.
Overpowered tool permissions: An MCP Server with read-write filesystem access, combined with a prompt injection attack, could be coerced into deleting files or leaking sensitive data. Our rule: each Server exposes minimum necessary permissions. Read and write are separate scopes. Production databases get read-only.
Prompt injection via tool results: If an Agent uses tools to read external content (web scraping, email parsing), that content might contain "ignore previous instructions" injections. We wrap any Agent that ingests external data with moltguard as a filter layer.
Third-party Server trust: When using someone else's MCP Server, review the code. A remote MCP Server could be logging all your requests or returning tampered data. Trust is a design decision, not a given.
MCP doesn't enforce security — that's on the architecture you build around it.
What to Watch in 2026
Remote MCP (HTTP+SSE) maturing: Most Servers today are locally deployed. As remote MCP matures, "Agent as a Service" becomes viable — no local Server setup, just connect to cloud-hosted tools.
Authentication standardization: Right now MCP has no built-in auth standard. HTTP Basic Auth or env-var tokens are the norm. The community is discussing more unified approaches — this will likely move in 2026.
Agent-to-Agent MCP: One Agent acting as another Agent's MCP Server. This pattern is being explored, and in multi-agent architectures like ours, it opens up interesting collaboration patterns.
SFD Lab's Take
Our honest read: MCP is a well-designed, directionally correct protocol, but the ecosystem is still early. Server stability varies. Documentation gaps exist.
Recommended approach: start with Anthropic's official reference Servers — stability is solid. For community Servers, read the code first. When building your own Server, start with read-only operations; add writes only after it's tested and stable.
MCP's value isn't where it is today — it's the momentum behind it. More tools are adding support. More AI applications are integrating Clients. That convergence has its own gravity, and it's pointing somewhere real.