RAG像盲人摸象，Function Calling累成狗，MCP怎么解决？ (English)

Generated: 2026-06-22 06:16:39

---

Okay, I checked the facts as you requested, corrected inaccuracies, removed the AI-generated tone, and adjusted the pacing. Here's the revised final version:

---

Scared by the word "protocol"? Let's see what MCP really is.

Honestly, the first time I saw the three letters MCP, my immediate thought was—another protocol? Is this another one of those "looks great on paper, falls apart in practice" things?

You probably feel the same way, right? The tech world is full of new concepts—a framework today, a protocol tomorrow, a standard the day after. It's dizzying.

But after I actually got my hands dirty and played around with it, I changed my mind.

This thing? It's actually pretty interesting.

---

First, let's talk about two old friends you love and hate

To understand MCP, you need to see how we got here.

RAG (Retrieval-Augmented Generation)—you're probably familiar with this, right? You chop your knowledge base into chunks, convert them into vectors, and store them in a database. When a user asks a question, you search the database for relevant snippets, stitch them into the prompt, and send it all to the LLM.

The upside: no need to fine-tune the model. Saves time and money. The downside? You never really know if what you retrieve is actually useful.

Speaking of which, let me share a pitfall I fell into.

There was a project using RAG for a customer service knowledge base. A user asked, "How do I get a refund?" The system matched the "Refund Policy" table of contents page—you know, the one with just a few headings and no actual content. What could the LLM do? It had to make stuff up based on those headings! The generated answer was miles off from the actual process.

The user was furious. So was I.

You think RAG is a magic key? It's really just a blind man feeling an elephant.

Function Calling is a different approach. The model decides which tool to call based on the user's input, the backend executes the actual request, and then the result is used to generate a response. This mechanism is pretty mature on platforms like Bailian and Azure OpenAI.

But here's the problem: every platform has its own Function Calling implementation, and the tool interfaces are all over the place. You write a tool for one platform, and you have to rewrite it for another.

That's the so-called "M×N problem"—M models, N tools, requiring M×N integration methods.

Tiring, isn't it?

Yeah, tiring.

---

What exactly is MCP? A USB-C story

On November 25, 2024, Anthropic open-sourced MCP. The official description: Model Context Protocol, an open standard that lets AI assistants connect to the systems where data lives.

In plain English: MCP is the USB-C port for AI applications.

Think about it—why is USB-C so great? Whether it's your phone, laptop, monitor, or power bank, you plug it in and it works. You don't care about the underlying protocol. You used to carry three cables; now one does it all.

MCP does the same thing—it lets AI models call various tools and data sources in a unified way.

MCP has three core components, dead simple:

• MCP Host: The AI application that integrates the MCP Client. For example, Claude Desktop, Cherry Studio, or your company's agent platform.
• MCP Client: Responsible for sending requests and receiving responses. You usually don't see it; it's hidden inside the Host, like a behind-the-scenes hero.
• MCP Server: A service that provides specific functionality. For example, querying a database, operating GitHub, or reading Figma designs.

The workflow goes like this: user asks a question → Host analyzes what tool is needed → Client calls the corresponding Server → Server returns the result → Host generates the answer based on the result.

In short, MCP decouples agent development from tool development.

People who write tools don't need to worry about how agents use them. People who write agents don't need to worry about how tools are implemented.

Everyone does their own thing, no interference. Perfect.

---

I got my hands dirty: Building an MCP Server from scratch, real pitfalls

Talk is cheap. I spent an afternoon following the official tutorial and hit quite a few snags. Let me share the real experience.

Environment setup:

• Python 3.10+
• Python MCP SDK 1.2.0+
• Claude Desktop (as MCP Host)
• uv (Astral's super-fast Python package manager, written in Rust, 100x faster than pip)

Honestly, when I first used uv, I thought, "Another new tool?"

But after using it, I was hooked. uv add mcp installed in a flash, way faster than pip. It felt like going from a bicycle to an electric scooter—awesome!

Writing the Server: My requirement was simple—read local files. Let Claude directly read files on my computer.

The code was generated by Claude 3.7. I said, "Write me an MCP Server that can read local files, just use the os module."

It wrote it out in no time. The core logic was just a dozen lines:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("file-reader")

@mcp.tool()
async def read_file(path: str) -> str:
 with open(path, 'r') as f:
 return f.read()

Testing: The official docs didn't mention testing, but I strongly recommend it. Use the MCP Inspector tool to debug the Server and see if it responds properly.

The first time I ran it, I got an error because the uv path wasn't set correctly. I used which uv to get the absolute path, fixed the config file, and it worked.

Integrating with Claude Desktop: Added the Server info to Claude Desktop's config file, restarted the app. If you see your Server in the MCP Server list, you're good.

Then I tried a prompt: "Read the notes.txt file on my desktop."

Claude popped up an authorization request. I clicked Allow.

It actually read the file content and even summarized it for me.

At that moment, I thought: This thing can actually do real work! It's not just a PowerPoint pipe dream!

---

MCP's ecosystem: More capable than you think

The MCP ecosystem is already quite rich. Let me list a few practical ones so you can get a feel:

• Slack MCP: Search messages, send messages, create channels. Great for automatically syncing project progress.
• Database MCP: Query databases directly, no need to manually copy SQL results.
• Figma MCP: Read design files, convert designs directly into code. A blessing for designers and developers.
• GitHub MCP: Manage repos, Issues, PRs. Automate project management.
• Browser MCP: Control Chrome, take screenshots, fill forms, read web pages.

Think about it—how much glue code would you have to write to make an AI do all this before? Now just configure an MCP Server and you're done.

This isn't just an efficiency improvement; it's an efficiency revolution.

---

An easily overlooked point: Hooks are the real killer feature

Claude Desktop also provides a Hooks mechanism that can automatically trigger scripts before or after tool calls. For example:

• PreToolUse: Triggered before Claude calls a tool. Can be used to intercept dangerous operations, like preventing file deletion.
• PostToolUse: Triggered after a tool call. Can automatically format code, run tests.

I tried the PostToolUse Hook: I had Claude automatically run eslint --fix after every JS/TS file modification. It directly generated the configuration, wrote it into .claude/settings.json in the project directory, and verified it worked.

Honestly, this is way more convenient than setting up lint checks in CI/CD. Because the Hook is enforced at the platform level, Claude can't forget it even if it wanted to.

Think about what this means: Your AI assistant is no longer a "use and forget" dummy, but a smart helper with "memory, habits, and rules."

---

MCP and OpenAI Agent SDK: If even competitors are using it, what does that tell you?

On March 11, 2025, OpenAI released the Agent SDK, introducing the Multi-Agent concept. You can define multiple domain-specific agents and have them collaborate on complex tasks.

Interestingly, the OpenAI Agent SDK also supports MCP.

What does that tell you? It means MCP is becoming an industry standard, even competitors are adopting it.

Currently, Coze and Tencent Cloud's agent development platform already support Multi-Agent mode. The pace of agent development is faster than I imagined.

Think about it—before, it was