MCP 深度解析：当 AI Agent 从「纸上谈兵」走向「动手执行」——Model Context Protocol 工程全解

前言：当大模型遇到数据孤岛

2024 年 11 月 25 日，Anthropic 发布了一份不起眼的技术公告，却悄然掀起了 AI 应用架构的一场静默革命。

这份公告的核心内容只有一个：Model Context Protocol（MCP）——一个开放协议，旨在标准化大型语言模型（LLM）与外部数据源、工具之间的通信方式。

消息发布后的三个月里，这个协议在开发者社区引发的连锁反应远超预期：BlenderMCP 上线 3 天斩获 3.8k GitHub Stars，让 Claude 实现了「动嘴做 3D」；Cursor 和 Cline 迅速集成 MCP 支持；LangChain、LlamaIndex 等主流 Agent 框架开始全面拥抱这一标准；GitHub 上围绕 MCP 的开源项目呈爆发式增长。

但如果你问一个普通开发者「什么是 MCP」，十有八九得到的回答是「就是那个 Manus 带火的东西」。这个回答既对又不对——对的是，Manus 确实让 MCP 进入了大众视野；不对的是，MCP 的本质远不止是一个 Agent 工具调用框架，它正在解决一个困扰 AI 行业两年之久的根本性问题：大模型的数据孤岛困境。

本文将深入解析 MCP 的设计哲学、协议架构、代码实现，并结合 BlenderMCP、文件系统 MCP、浏览器 MCP 等真实案例，从工程视角理解这一协议如何重新定义 AI 应用的边界。

一、问题的本质：大模型为何是「盲人」？

1.1 两年的挣扎：Function Calling 的兴与衰

要理解 MCP 的价值，先要理解在它出现之前，开发者们走了多少弯路。

从 2022 年底 ChatGPT 横空出世开始，开发者就在探索同一个问题：如何让大模型真正「动手」做事，而不是只输出文字？

第一代解决方案是 Prompt Engineering——在提示词里教模型调用某个 API。但这种方式极度脆弱，一旦模型对 API 参数理解有误，整个流程就会崩溃。

2023 年，OpenAI 率先在 GPT-4 中引入 Function Calling（函数调用）机制，随后各大模型厂商纷纷跟进。这套机制的核心逻辑是：在模型输出之前，先告诉它有哪些工具可用，每个工具的 JSON Schema 是什么，然后模型根据对话上下文决定调用哪个工具，并生成符合 Schema 的参数。

Function Calling 相比纯 Prompt 有了质的飞跃，但它有一个致命缺陷——每个 Agent 应用都需要重复实现同一套「工具发现 → 工具描述 → 工具调用」的逻辑。如果你在 Cursor 里写了一个文件搜索工具，想在 Claude Desktop 里复用，你需要把所有工具定义重新写一遍。更糟糕的是，每个工具的 Schema 是硬编码在提示词里的，无法动态发现。

1.2 数据孤岛：AI 应用的阿喀琉斯之踵

Function Calling 的碎片化只是表象，更深层的问题是数据孤岛。

让我们把视角拉高，看一个典型 AI Agent 的工作流程：

用户对 Claude 说：「帮我看看我的邮箱里有没有来自 HR 的未读邮件。」

这个请求背后，Claude 需要：

• 连接用户的邮件服务器（IMAP/Gmail API）
• 获取未读邮件列表
• 筛选出 HR 发来的邮件
• 返回摘要

在 Function Calling 模式下，你需要：

1. 为邮件服务写一个专用的 Function Schema
2. 在提示词里描述这个工具的用法
3. 实现一个调用邮件 API 的函数
4. 部署到生产环境

如果第二天你又想「让 Claude 查一下我的日历」，你又要重复以上步骤——重新定义日历工具的 Schema，重新实现调用逻辑。而且，这个日历工具和邮件工具之间没有任何共享机制，它们是完全孤立的存在。

更严重的是安全隔离问题：在 Function Calling 模式下，API Key 和敏感凭据通常需要嵌入到 Agent 代码里。这意味着任何可以访问 Agent 代码的人，都可能接触到这些敏感信息。

MCP 的出现，正是为了解决这三个根本性问题：

• 标准化：一套协议，所有 AI 工具复用
• 动态发现：Agent 启动时自动发现可用工具，而非硬编码
• 安全隔离：敏感凭据由用户本地管理，Agent 只接收结果

二、MCP 协议架构：从 USB 到 AI 数据总线

2.1 核心类比：AI 系统的 USB 标准

Anthropic 在发布 MCP 时，用了一个精准的类比：MCP 就是 AI 系统的 USB 标准。

在 USB 出现之前，打印机、鼠标、键盘、摄像头各有各的接口，厂商要为每种设备编写专门的驱动程序。USB 的出现彻底改变了这一局面——一个通用接口，让任何 USB 设备可以连接到任何 USB 端口，设备驱动的问题由操作系统统一处理。

MCP 之于 AI 应用，正是这样一场接口革命。在 MCP 出现之前，每个 AI 应用与外部工具的集成都是「私有协议」：LangChain 有 LangChain 的 Tool 接口，LlamaIndex 有 LlamaIndex 的 Tool 接口，GPTs 有 GPTs 的 Action 接口。它们之间无法互通，一个在 LangChain 里写的工具无法直接在 Claude Desktop 里使用。

MCP 的目标是：让工具提供商只需要实现一次 MCP Server，就能在所有支持 MCP 的 AI 应用中复用。就像一个 USB 摄像头，插在任何 USB 端口上都能工作。

2.2 三元架构：Host、Client 与 Server

MCP 协议采用经典的 C/S 架构，但引入了「Host」层来协调多个 Client 的生命周期。这套架构的设计非常精妙，我们逐一拆解。

MCP Host（宿主应用）

Host 是用户直接交互的 AI 应用本身——Claude Desktop、Cursor IDE、Claude Code 等。Host 的职责是：

• 管理整个 MCP 会话的生命周期
• 协调多个 MCP Client 的并发请求
• 向用户呈现 Agent 的执行结果

你可以把 Host 理解为「USB 控制器」，它负责总线的管理，但不直接参与具体的数据传输。

MCP Client（客户端）

每个外部工具或数据源对应一个独立的 MCP Client。Client 负责：

• 与对应的 MCP Server 建立并维护连接
• 处理协议的序列化/反序列化
• 将工具调用请求路由到对应的 Server

在 Claude Desktop 中，你可以同时连接文件系统的 MCP Server（用于读写本地文件）和邮件的 MCP Server（用于查收邮件），每个 Server 对应一个独立的 Client。

MCP Server（服务端）

Server 是工具和数据源的真正实现者。一个 MCP Server 通常对应一个特定的功能域，比如：

• filesystem Server：提供本地文件系统读写能力
• browser Server：提供浏览器自动化能力
• git Server：提供 Git 操作能力
• slack Server：提供 Slack 消息发送能力

Server 本身是轻量级程序，通过标准协议与 Client 通信。这意味着开发者可以独立开发、部署和更新每个 Server，而不影响其他组件。

2.3 传输层：Stdio 与 SSE 的双轨设计

MCP 协议在传输层支持两种模式：**Stdio（标准输入/输出）**和 SSE（Server-Sent Events）。

Stdio 模式是最常用的本地通信方式。Server 作为一个子进程启动，通过 stdin/stdout 与 Client 交换 JSON-RPC 消息。这种方式的优点是：

• 零配置，无需网络
• 进程隔离，安全性高
• 部署简单，适合本地工具

SSE 模式适用于需要远程连接或需要 Server 主动推送数据的场景。在这种模式下，Client 通过 HTTP POST 发送请求，Server 通过 SSE 流式返回响应。这种方式适合：

• 连接远程 MCP Server（如公司内部的数据库服务）
• 需要实时数据推送的场景（如监控系统）

两种传输模式对上层协议完全透明，开发者可以根据场景灵活选择。

2.4 协议消息：JSON-RPC 2.0 的标准化实践

MCP 协议的消息格式基于 JSON-RPC 2.0——一个成熟、简洁的远程过程调用（RPC）标准。选择 JSON-RPC 而非自定义格式，是 MCP 设计中最明智的决策之一：

• 无状态友好：每个请求/响应独立，适合 HTTP 和 WebSocket 等无状态协议
• 工具链成熟：几乎所有编程语言都有成熟的 JSON-RPC 库
• 调试简单：JSON 格式可读性强，便于开发者调试
• 生态兼容：可以复用大量现有的 JSON-RPC 工具和中间件

MCP 的核心消息类型包括：

initialize        → Client 发起初始化握手
initialized       → Server 确认初始化完成
tools/list        → Client 请求 Server 列出可用工具
tools/call        → Client 调用指定工具
resources/list    → Client 请求 Server 列出可用资源
resources/read    → Client 读取指定资源
prompts/list      → Client 请求 Server 列出可用提示模板
roots/list        → Client 请求工作区根目录信息
sampling/create   → Client 请求 Server 创建一个采样请求

每条消息都是标准的 JSON-RPC 2.0 格式，包含 jsonrpc、method、params 和 id 字段。

三、工具（Tools）体系：MCP 的核心能力

3.1 工具定义：从 Schema 到可执行动作

Tools 是 MCP 协议中最核心的概念，它将外部能力标准化为 AI 可理解和调用的「动作」。

一个 MCP 工具的定义包含以下字段：

{
  "name": "filesystem_read",
  "description": "读取本地文件的内容",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string",
        "description": "要读取的文件路径（绝对路径或相对路径）"
      },
      "encoding": {
        "type": "string",
        "description": "文件编码，默认为 utf-8",
        "default": "utf-8"
      }
    },
    "required": ["path"]
  }
}

这个 Schema 会被发送到 AI 模型，模型根据用户对话决定是否调用该工具，以及填充什么参数。

3.2 工具调用的完整流程

让我们通过一个具体场景，深入理解 MCP 工具调用的完整生命周期：

场景：用户在 Claude Desktop 中说「帮我看看 /tmp/notes.md 里写了什么」。

Step 1：动态发现
Claude Desktop 启动时，会向所有已连接的 MCP Server 发送 tools/list 请求。文件系统 Server 返回可用的工具列表，其中包含 filesystem_read 工具及其 Schema。

Step 2：意图识别
用户输入被发送给 Claude。Claude 分析后发现，用户请求涉及文件读取，而当前已知的可用工具中，filesystem_read 正好可以满足这个需求。Claude 决定调用该工具。

Step 3：参数生成
Claude 根据用户输入和工具 Schema，生成调用参数：

{
  "name": "filesystem_read",
  "arguments": {
    "path": "/tmp/notes.md"
  }
}

Step 4：协议封装
Claude Desktop 的 MCP Client 将调用封装为 JSON-RPC 消息，通过 Stdio 管道发送给文件系统 Server：

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "filesystem_read",
    "arguments": {"path": "/tmp/notes.md"}
  },
  "id": 42
}

Step 5：执行与响应
文件系统 Server 读取 /tmp/notes.md，将结果封装为 JSON-RPC 响应：

{
  "jsonrpc": "2.0",
  "result": {
    "content": [
      {
        "type": "text",
        "text": "# 笔记\n\n这是一个测试文件。\n"
      }
    ]
  },
  "id": 42
}

Step 6：结果展示
Claude Desktop 收到响应后，将文件内容展示给用户。整个过程中，用户完全感知不到底层的协议交互，就像在和一个能直接访问本地文件的 AI 对话。

3.3 与 Function Calling 的本质区别

理解了 MCP 的工具调用流程后，我们来对比它与传统 Function Calling 的核心差异：

MCP 并不是要替代 Function Calling——事实上，Function Calling 是 MCP 在模型层的实现机制之一。MCP 解决的是 Function Calling 之上的「协议层」问题：让工具的定义、发现、调用和授权成为一个标准化、可复用的流程。

四、实战：用 Python 从零构建一个 MCP Server

4.1 环境准备

MCP 官方提供了 Python 和 TypeScript 两种 SDK。以 Python 为例，首先安装依赖：

pip install mcp

4.2 基础 Server 结构

以下是一个极简的 MCP Server 实现，它提供了两个工具：读取文件和搜索文件内容：

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

# 创建 Server 实例
server = Server("demo-filesystem")

@server.list_tools()
async def list_tools() -> list[Tool]:
    """声明 Server 提供的工具列表"""
    return [
        Tool(
            name="read_file",
            description="读取指定路径的文件内容",
            inputSchema={
                "type": "object",
                "properties": {
                    "path": {
                        "type": "string",
                        "description": "文件路径（绝对路径）"
                    },
                    "max_lines": {
                        "type": "integer",
                        "description": "最多读取的行数，默认 1000",
                        "default": 1000
                    }
                },
                "required": ["path"]
            }
        ),
        Tool(
            name="search_in_file",
            description="在文件中搜索包含指定关键词的行",
            inputSchema={
                "type": "object",
                "properties": {
                    "path": {
                        "type": "string",
                        "description": "文件路径"
                    },
                    "keyword": {
                        "type": "string",
                        "description": "要搜索的关键词"
                    }
                },
                "required": ["path", "keyword"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    """处理工具调用请求"""
    
    if name == "read_file":
        path = arguments["path"]
        max_lines = arguments.get("max_lines", 1000)
        
        if not os.path.exists(path):
            raise ValueError(f"文件不存在: {path}")
        
        with open(path, "r", encoding="utf-8") as f:
            lines = [f.readline() for _ in range(max_lines)]
            content = "".join(lines)
        
        return [TextContent(type="text", text=content)]
    
    elif name == "search_in_file":
        path = arguments["path"]
        keyword = arguments["keyword"]
        
        if not os.path.exists(path):
            raise ValueError(f"文件不存在: {path}")
        
        matches = []
        with open(path, "r", encoding="utf-8") as f:
            for i, line in enumerate(f, 1):
                if keyword in line:
                    matches.append(f"{i}: {line.rstrip()}")
        
        if not matches:
            return [TextContent(type="text", text=f"未找到包含 {keyword} 的内容")]
        
        return [TextContent(
            type="text",
            text=f"找到 {len(matches)} 处匹配:\n\n" + "\n".join(matches)
        )]
    
    else:
        raise ValueError(f"未知工具: {name}")

async def main():
    """启动 Server"""
    async with stdio_server() as (read_stream, write_stream):
        await server.run(
            read_stream,
            write_stream,
            server.create_initialization_options()
        )

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

4.3 Server 配置与连接

Server 写好后，需要在 Claude Desktop 或其他 Host 应用中进行配置。配置文件位于：

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

{
  "mcpServers": {
    "demo-filesystem": {
      "command": "python",
      "args": ["/path/to/your/server.py"],
      "env": {
        "ALLOWED_PATHS": "/tmp,/Users/username/projects"
      }
    }
  }
}

配置完成后，重启 Claude Desktop，新工具就会自动出现在可用工具列表中。

4.4 进阶：加入资源（Resources）支持

除了 Tools，MCP 还支持 Resources——一种让 AI 主动读取数据的机制。与 Tools 的「AI 主动调用」不同，Resources 更像是「AI 按需读取」的数据源。

@server.list_resources()
async def list_resources() -> list[Resource]:
    """声明可访问的资源"""
    return [
        Resource(
            uri="file:///tmp/notes.md",
            name="工作笔记",
            description="我的日常工作和想法记录",
            mimeType="text/markdown"
        ),
        Resource(
            uri="file:///tmp/todos.json",
            name="待办事项",
            description="当前待完成的任务列表",
            mimeType="application/json"
        )
    ]

@server.read_resource()
async def read_resource(uri: AnyUrl) -> str:
    """处理资源读取请求"""
    path = uri.path
    with open(path, "r", encoding="utf-8") as f:
        return f.read()

Resources 的价值在于：AI 可以主动「查看」数据源的内容，而无需用户手动上传文件。这对于需要 AI 分析本地日志、配置、代码库等场景尤为有用。

五、生态全景：从 Blender 到生产环境

5.1 BlenderMCP：最直观的 MCP 能力展示

在所有 MCP 应用中，BlenderMCP 是最能让人直观感受到协议威力的案例。

GitHub: github.com/ahujasid/blender-mcp

BlenderMCP 将 Claude（或其他支持 MCP 的模型）与 Blender 3D 建模软件连接起来。用户只需要用自然语言描述想要的 3D 场景，Claude 就能自动控制 Blender 创建模型。

实际效果（来自社区用户的测试）：

提示词："Create a low poly scene with a dragon guarding a pot of gold in a dungeon"

结果：Claude 自动调用 Blender 的 Python API，生成了一个低多边形风格的地牢场景，包含龙的 3D 模型、金罐、环境光照等。整个过程无需人工干预。

BlenderMCP 的架构非常精巧：

用户自然语言 → Claude（分析意图）
                        ↓
              MCP Client → BlenderMCP Server（通过 Socket 连接）
                        ↓
              Blender Python API → 3D 场景渲染

Server 与 Blender 之间通过 Socket 通信（端口 9876），这意味着 Server 可以运行在本地，也可以部署在远程机器上。这种设计保证了 MCP 协议的传输层抽象与实际执行环境的解耦。

5.2 主流 MCP Server 一览

MCP 生态已经涌现出大量高质量的 Server 实现，涵盖了开发、数据、办公等多个领域：

开发工具类

• filesystem：本地文件系统读写
• git：Git 操作（commit、push、branch 等）
• github：GitHub API 集成（issues、PRs、repos）
• brave-search：网页搜索

数据类

• sqlite：SQLite 数据库查询
• postgres：PostgreSQL 数据库连接
• memory：跨会话的持久化记忆存储

办公类

• slack：发送和读取 Slack 消息
• gmail：邮件读写
• google-calendar：日程管理

AI 工具类

• puppeteer：浏览器自动化（网页截图、内容提取）
• openapi：调用任意 REST API

这种生态的爆发式增长，印证了 MCP 协议设计的成功——开发者只需要写一个 Server，就能让所有 Host 应用受益。

5.3 企业级场景：从单工具到工具链

在企业级场景中，MCP 的价值更加突出。考虑这样一个工作流：

一个数据分析师的 AI 助手，需要完成以下任务：

1. 从 PostgreSQL 中查询销售数据
2. 用 Python 进行数据清洗和可视化
3. 生成报告并发送到 Slack 频道
4. 在 Notion 中创建任务跟踪记录

在 MCP 出现之前，这个流程需要：

• 为每一步写定制化的集成代码
• 管理多套 API 凭据
• 处理不同系统之间的数据格式转换

有了 MCP，流程变成：

1. 配置 postgres MCP Server 连接数据库
2. 配置 filesystem MCP Server 管理 Python 脚本
3. 配置 slack MCP Server 发送消息
4. 配置 notion MCP Server 创建记录

AI Agent 可以在运行时动态发现所有可用工具，并根据任务需求自主编排调用顺序。这种工具链的可组合性，是 MCP 给企业级 AI 应用带来的最本质改变。

六、安全模型：MCP 的设计哲学

6.1 信任边界：本地优先的设计

MCP 在安全设计上有一个核心原则：敏感操作发生在用户本地，AI 模型只接收结果。

以文件系统操作为例：当 Claude 读取一个文件时，真正执行读取操作的是用户本地的 MCP Server，而 Claude 收到的只是文件内容字符串。这意味着：

• API Key 和凭据存储在用户的本地环境中，不暴露给 AI 模型
• 文件系统访问由用户本地的 Server 控制，可以添加权限检查
• 即使 AI 模型被攻击，攻击者也无法直接访问文件系统

6.2 多因素授权：用户知情权

MCP 设计中另一个重要的安全考量是用户对工具调用的知情权。

在 Claude Desktop 中，每次 MCP 工具调用都需要用户确认（除非用户主动关闭该设置）。这确保了：

• 用户知道 AI 正在执行什么操作
• 用户有机会在危险操作执行前中止
• 敏感数据（如文件内容）在展示给用户前经过 Server 的过滤

6.3 当前已知的安全注意事项

2025 年 3 月，国家网络安全通报中心指出了 Ollama 默认配置存在的安全风险（与 MCP 类似，都是 AI 工具的远程调用场景）。对于 MCP 部署，以下是开发者需要注意的事项：

1. 避免在公网暴露 MCP Server：默认情况下，Stdio 模式的 Server 仅监听本地端口，但 SSE 模式需要配置防火墙
2. 定期更新 Server 依赖：很多 MCP Server 依赖第三方库，及时打补丁很重要
3. 最小权限原则：每个 Server 只授予完成其功能所需的最小权限，不要让文件系统 Server 有执行系统命令的能力

七、局限性：MCP 不是什么？

7.1 不是银弹

MCP 解决了工具调用的标准化问题，但并没有解决以下问题：

模型能力问题：如果模型本身不理解你的业务逻辑，给它再多的工具也无法改善输出质量。MCP 只是提供了一个更好的「调用界面」，但调用的「策略」仍然取决于模型。

复杂工作流编排：对于需要数十个工具、多步骤决策的复杂工作流，MCP 本身没有编排能力。这部分需要由 LangChain、AutoGPT 等 Agent 框架来处理，MCP 是它们的下层协议。

实时性：MCP 的通信基于请求/响应模式，不适合需要毫秒级响应的实时交互场景（如在线游戏、股票交易）。

7.2 Server 质量参差不齐

MCP 生态的爆发式增长也带来了一个问题：Server 质量参差不齐。一些 Server 存在：

• 不完整的 Schema 定义，导致模型无法正确理解工具用法
• 缺少错误处理，异常情况下返回格式不规范的响应
• 性能问题，大文件读写没有流式处理

在生产环境中，选择经过充分测试的 Server 或自行实现核心 Server 是更稳妥的选择。

八、未来展望：MCP 的演进方向

8.1 协议层面的演进

MCP 目前仍处于快速迭代阶段，以下几个方向值得关注：

流式响应（Streaming）：当前的 MCP 工具调用是全量响应，但对于大文件读取、长文本生成等场景，流式响应能显著改善用户体验。

增量工具更新：目前 Server 启动时一次性注册所有工具，未来可能支持运行时动态添加/移除工具。

更好的调试工具：随着 MCP 生态的成熟，可视化的协议调试工具（类似 Postman 对于 REST API 的意义）将成为刚需。

8.2 生态层面的演进

MCP Registry：类似 npm 的 MCP Server 注册中心，让开发者可以搜索、安装和分享 MCP Server。

企业级 MCP Gateway：在企业环境中，可能需要一个统一的 MCP Gateway 来管理多个 Server、进行访问控制和审计。

跨 Host 兼容：目前不同的 Host（Claude Desktop、Cursor、Cline）对 MCP 的支持程度不一，随着协议成熟，这些差异将逐步缩小。

8.3 AI 应用架构的范式转移

从更宏观的视角看，MCP 代表了 AI 应用架构的一次范式转移：从「AI + 工具」到「AI 即平台」。

在旧的范式中，AI 是一个「大脑」，工具是外挂的「手脚」，两者之间需要大量定制代码来协调。在新的范式中，MCP 构建了一个「AI 数据总线」，任何工具只要遵循协议就能接入，AI 应用变成了一个可插拔的平台。

这种范式转移的影响是深远的：

• 工具开发者的成本大幅降低：只需要实现一次 MCP Server，就能接入所有 AI 生态
• AI 应用的功能边界大幅扩展：通过连接更多 Server，AI 应用的能力可以无限扩展
• 用户获得了真正的「AI PC」体验：AI 能够像人一样操作本地文件、使用各种软件

结语：AI 的「动手能力」元年

2025 年，被很多人称为「AI Agent 元年」。但如果你仔细观察会发现，真正让 Agent 从「能说会道」走向「能征善战」的，恰恰是 MCP 这类协议的出现。

Function Calling 让 AI 知道了「有什么工具可以用」，而 MCP 让 AI 知道了「如何标准化地使用工具」。前者是能力，后者是生态。

BlenderMCP 3 天 3.8k Stars 的背后，不是一个 3D 工具的爆火，而是一种新范式的确认：当 AI 能够用自然语言控制任何支持 MCP 的软件时，「动嘴编程」就不再是噱头，而成为了现实。

对于开发者而言，现在是深入理解 MCP 的最佳时机。协议还在快速演进，生态还没有固化，现在入局，你既是用户，也是塑造者。

下一次当你对着 Claude 说「帮我把这些文件整理一下」的时候，不妨想一想背后发生的一切——JSON-RPC 消息穿越 Stdio 管道，MCP Server 解析请求、调用系统 API、返回结果。这条链路上的每一个环节，都在等待被理解、被优化、被扩展。

这就是 MCP 给我们的礼物：不是答案，而是一套提问的方式。

参考资料

• Model Context Protocol 官方文档: modelcontextprotocol.io
• MCP Python SDK: github.com/modelcontextprotocol/python-sdk
• MCP TypeScript SDK: github.com/modelcontextprotocol/typescript-sdk
• BlenderMCP: github.com/ahujasid/blender-mcp
• Anthropic 官方公告（2024.11.25）: anthropic.com/news/model-context-protocol