MCP 协议实战：给你的 AI 装上真正的手和眼

What MCP Is

MCP stands for Model Context Protocol. It’s an open protocol published by Anthropic that defines a standard way for AI models to interact with external tools, data sources, and services.

The core problem it solves: AI models are isolated by default. They can reason about text, but they can’t read files, query databases, call APIs, or interact with anything outside their context window — unless you build an explicit bridge.

MCP is that bridge, standardized.

Before MCP, every tool integration was custom. You’d write function definitions in whatever format the model expected, handle the execution yourself, and pass results back. This worked, but each integration was its own project.

With MCP, tool integrations follow a common protocol. A server you build for one MCP-compatible client works with any MCP-compatible client. The integration is reusable and composable.

Three Capabilities

MCP exposes three types of capabilities:

Tools

Functions the model can call. The model receives a description of the tool, decides when to call it, sends a request, and receives a result. Tools are the most commonly used capability — they’re how you give the model “hands.”

Examples: search the web, read a file, send a Feishu message, run a SQL query, get the current time.

Resources

Data sources the model can read. Unlike tools, resources are passive — they expose content that the model can pull when needed. Think of them as a structured way to make external data available in context.

Examples: a project’s documentation, a database schema, a configuration file, a list of available endpoints.

Prompts

Reusable prompt templates that can be invoked by name. Less commonly used than Tools or Resources, but useful for standardizing complex prompt structures across sessions.

A Minimal MCP Server in Python

Here’s a working MCP server that exposes a single tool: searching blog posts by keyword.

from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
import json
import os
import re

app = Server("blog-search")

# Load blog posts at startup
BLOG_DIR = "/path/to/your/content/blog"

def load_posts():
    posts = []
    for filename in os.listdir(BLOG_DIR):
        if filename.endswith(".md"):
            filepath = os.path.join(BLOG_DIR, filename)
            with open(filepath, "r") as f:
                content = f.read()
            posts.append({"filename": filename, "content": content})
    return posts

POSTS = load_posts()

@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="search_blog",
            description="Search blog posts by keyword. Returns matching post filenames and relevant excerpts.",
            inputSchema={
                "type": "object",
                "properties": {
                    "query": {
                        "type": "string",
                        "description": "The keyword or phrase to search for"
                    }
                },
                "required": ["query"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict):
    if name != "search_blog":
        raise ValueError(f"Unknown tool: {name}")

    query = arguments["query"].lower()
    results = []

    for post in POSTS:
        if query in post["content"].lower():
            # Extract a short excerpt around the match
            idx = post["content"].lower().find(query)
            start = max(0, idx - 100)
            end = min(len(post["content"]), idx + 200)
            excerpt = post["content"][start:end].strip()
            results.append({
                "file": post["filename"],
                "excerpt": f"...{excerpt}..."
            })

    if not results:
        return [TextContent(type="text", text="No matching posts found.")]

    output = json.dumps(results, indent=2, ensure_ascii=False)
    return [TextContent(type="text", text=output)]

async def main():
    async with stdio_server() as streams:
        await app.run(streams[0], streams[1], app.create_initialization_options())

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

This server communicates over stdio. Claude Desktop (or any MCP-compatible client) starts the server as a subprocess and communicates with it via stdin/stdout.

Registering in claude_desktop_config.json

Once your server is written, register it in Claude Desktop’s configuration:

{
  "mcpServers": {
    "blog-search": {
      "command": "python",
      "args": ["/path/to/your/blog_search_server.py"],
      "env": {}
    }
  }
}

The config file is at:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Restart Claude Desktop after editing. The tools will appear in the model’s available toolset for that session.

For development, I run the server with extra logging enabled and watch the output in a separate terminal. Debugging MCP servers is much easier when you can see exactly what’s being sent and received.

Tools I Actually Use

context7

Fetches up-to-date documentation for libraries. When I’m working with a framework I haven’t used recently, instead of hoping the model’s training data is current, I call context7 to pull the actual docs. It’s the single most useful MCP tool I’ve added.

filesystem tools

Read, write, and list files outside the default working directory. Useful for agents that need to reach across project boundaries — for example, a coordinator that needs to read from a sibling service’s directory.

Custom Feishu tools

Tools I built myself for sending messages, reading inbox, and querying group membership in Feishu (Lark). These are what the Liaison agent uses to bridge AI reasoning with the messaging platform. The MCP interface means I can invoke them from Claude Desktop during development and from the agent’s runtime in production, with the same tool definitions.

Principles for Designing Good MCP Tools

One tool, one clear job. Don’t build a do_everything tool that takes a mode parameter. Build search_posts, create_post, and update_post as separate tools. The model reasons better about focused tools.

Descriptions are load-bearing. The tool description is what the model reads to decide whether to call the tool. Write it like documentation for a developer who doesn’t know your system — precise about what the tool does, what it returns, and what it won’t do.

Return structured data, not prose. JSON or structured text is easier for the model to parse and reason about than a narrative response. Save prose for human-facing output.

Fail loudly. Return clear error messages when something goes wrong. “File not found at /path/to/file” is infinitely more useful than an empty result or a generic error string. The model can adapt its behavior based on informative errors; it can’t do much with silence.

Keep side effects explicit. If a tool modifies state — writes a file, sends a message, updates a record — say so clearly in the description. The model needs to know the difference between read-only and write tools to plan correctly.

MCP vs Function Calling

Function calling is faster to prototype. MCP is better for tools you’ll use repeatedly across different contexts and clients.

In practice, I use function calling for one-off integrations and MCP for anything that’s become a permanent part of the workflow.

Next Steps

If you want to go further:

• MCP specification: modelcontextprotocol.io — the full protocol docs
• Python SDK: pip install mcp — the official Anthropic SDK for building servers
• Inspector: the MCP inspector tool lets you test a server interactively without spinning up a full client
• Claude Desktop as a test harness: once a server is registered, you can test it by asking Claude to use the tool in a normal conversation

The pattern I’d recommend: pick one thing you repeatedly wish Claude could access — a local database, an internal API, a set of project files — and build the smallest possible MCP server that exposes it. Get that working. Then extend it.

The value compounds. Each tool you add makes the model more capable in that context, and the MCP standard means each tool is reusable across future projects.