MCP 协议概述与架构设计

1. 什么是 Model Context Protocol？

Model Context Protocol（MCP）是 Anthropic 在 2024 年推出的开放标准协议，旨在解决 AI 助手与外部世界交互时面临的碎片化问题。在 MCP 出现之前，不同的 AI 应用各自发明自己的工具调用格式：有的用 JSON Schema 描述函数，有的用自定义 DSL，有的直接把代码注入提示词。这种混乱导致工具开发者需要为每个平台重复编写适配代码，而 AI 应用也难以复用现有的工具生态。

MCP 的核心思想是将 AI 助手的上下文管理抽象为一个标准化的客户端-服务器协议。在这个模型中：

• MCP Host：运行 AI 助手的应用程序（如 Claude Desktop、Cursor、自定义聊天机器人）
• MCP Client：Host 中的协议客户端，负责与服务器通信
• MCP Server：提供工具、资源和 Prompt 的外部服务
• Local Data Source：服务器可访问的本地数据（文件、数据库、配置）
• Remote Services：服务器可访问的远程 API（云服务、SaaS）

这种分层设计的最大优势是工具提供商只需实现一次 MCP Server，所有 MCP Host 都可以直接使用。这类似于 USB 协议让外围设备可以连接任何电脑，或者 HTTP 协议让网站可以被任何浏览器访问。

2. MCP 的核心概念

2.1 Tools（工具）

Tools 是 MCP 最基本的能力单元。服务器声明一组可供 AI 调用的工具，每个工具包含名称、描述和参数模式（JSON Schema）。当 AI 判断需要调用工具时，Host 通过客户端向服务器发送请求，服务器执行操作后返回结果。

{
  "tools": [
    {
      "name": "read_file",
      "description": "读取指定路径的文件内容",
      "inputSchema": {
        "type": "object",
        "properties": {
          "path": {
            "type": "string",
            "description": "文件的绝对路径"
          }
        },
        "required": ["path"]
      }
    }
  ]
}

2.2 Resources（资源）

Resources 代表服务器可以提供的只读数据。与 Tools 不同，Resources 不是用来"做"事情，而是用来"获取"信息。它们通常有唯一的 URI，可以订阅变化通知。

{
  "resources": [
    {
      "uri": "file:///project/README.md",
      "name": "项目 README",
      "mimeType": "text/markdown"
    }
  ]
}

2.3 Prompts（提示词模板）

Prompts 提供预定义的提示词模板，帮助用户快速发起特定类型的对话。服务器可以声明 Prompts，Host 将其展示给用户选择。

{
  "prompts": [
    {
      "name": "code_review",
      "description": "审查代码变更并提供改进建议",
      "arguments": [
        {
          "name": "file_path",
          "description": "要审查的文件路径",
          "required": true
        }
      ]
    }
  ]
}

3. 协议架构分层

MCP 协议采用分层设计，从低到高依次是：

3.1 传输层（Transport Layer）

传输层负责客户端和服务器之间的消息传递。MCP 目前支持两种传输方式：

stdio 传输：服务器作为独立进程启动，通过标准输入输出与客户端通信。这是最简单的方式，适合本地工具。

# Claude Desktop 配置示例
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"]
    }
  }
}

HTTP with SSE 传输：基于 HTTP 的请求-响应模型，配合 Server-Sent Events 实现服务器到客户端的推送。这种方式适合远程部署和 Web 应用集成。

3.2 协议层（Protocol Layer）

协议层定义了消息的格式和交互模式。MCP 使用 JSON-RPC 2.0 作为基础，在此基础上定义了特定的请求和通知方法：

• 初始化 handshake：initialize 请求协商协议版本和能力
• 能力协商：双方交换支持的 features（tools、resources、prompts、logging 等）
• 消息类型：Requests、Responses、Notifications
• 生命周期管理：initialized 通知标志着正式通信开始

3.3 能力层（Capability Layer）

能力层定义了服务器可以提供的具体功能：

4. 生命周期管理

4.1 连接建立

MCP 连接建立遵循严格的握手协议：

Client                              Server
  |                                   |
  |--- initialize (capabilities) --->|
  |                                   |
  |<-- initialize (capabilities) ----|
  |                                   |
  |--- initialized (notification) -->|
  |                                   |
  |<===== 正常通信开始 ================|

初始化消息包含以下关键信息：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "tools": {},
      "resources": { "subscribe": true },
      "prompts": {}
    },
    "clientInfo": {
      "name": "claude-desktop",
      "version": "1.0.0"
    }
  }
}

4.2 连接维持

连接建立后，双方通过 ping 或应用层心跳保持连接活跃。对于 stdio 传输，连接随进程生命周期自然维持；对于 HTTP 传输，SSE 连接长期保持，期间可以复用已有的请求通道发送新请求。

4.3 优雅关闭

Client                              Server
  |                                   |
  |--- tools/call: some_tool() ----->|
  |                                   |
  |<-- result / error ----------------|
  |                                   |
  |--- cancel (if needed) ----------->|
  |                                   |
  |--- close notification ----------->|
  |                                   |
  |           [连接终止]              |

5. MCP vs Function Calling

MCP 与 OpenAI 的 Function Calling 虽然目标相似（让 AI 调用外部工具），但在设计哲学上有根本差异：

Function Calling 本质上是模型能力的一部分——模型在其输出中生成一个特殊的 JSON 对象表示工具调用意图。MCP 则是在此之上构建的完整协议层，定义了工具如何被发现、如何被调用、结果如何返回、错误如何传播。

实际应用中，MCP Host 内部可以调用支持 Function Calling 的模型，然后将模型的工具调用意图转换为 MCP tools/call 请求发送到 MCP Server。这种分层使得 MCP 不绑定特定的模型供应商。

6. 典型应用场景

6.1 文件系统访问

允许 AI 助手在受限目录内读取和修改文件：

用户: "帮我读取 src/main.rs 并解释其作用"
AI -> MCP Client -> MCP Server (filesystem)
Server: 返回文件内容
AI -> 向用户解释代码

6.2 数据库查询

让 AI 助手安全地查询数据库：

用户: "统计今天的订单数量和总金额"
AI -> MCP Client -> MCP Server (database)
Server: 执行 SELECT 查询
Server: 返回结果
AI -> 向用户展示统计数据

6.3 Git 操作

用户: "查看最近的提交历史"
AI -> MCP Client -> MCP Server (git)
Server: 执行 git log --oneline -10
AI -> 向用户展示提交列表

7. 安全考量

MCP 的设计中嵌入了多层安全机制：

7.1 权限边界

服务器只能访问其声明的能力范围内的资源。文件系统服务器只能访问配置时指定的目录，数据库服务器只能执行声明允许的查询类型。

7.2 用户确认

MCP 建议 Host 在调用可能产生副作用的工具前向用户确认。Claude Desktop 的实现会在执行 write_file 等操作前弹出确认对话框。

7.3 输入验证

所有工具参数必须通过 JSON Schema 验证，防止注入攻击。服务器应该在收到请求后再次验证参数的有效性。

8. 生态现状

截至 2025 年，MCP 生态已初具规模：

• 官方服务器：Anthropic 提供了文件系统、GitHub、PostgreSQL 、Slack 等官方 MCP Server
• 社区服务器：开源社区贡献了数百个 MCP Server，覆盖浏览器自动化、云服务商、API 网关等
• 客户端支持：Claude Desktop（原生）、Cursor（内置）、VS Code Copilot（实验性）
• SDK：官方提供 TypeScript 和 Python SDK，社区有 Go 、Rust 实现

9. 总结

MCP 代表了 AI 工具集成从"每个平台各自为政"走向"统一开放标准"的重要一步。它的核心价值在于：

1. 一次实现，到处使用：工具开发者编写一次 MCP Server，所有 MCP Host 都可用
2. 能力发现：AI 助手可以动态发现和学习可用工具，无需硬编码
3. 安全边界：通过标准化协议实现细粒度的权限控制
4. 去中心化：不绑定特定模型供应商，任何符合协议的 AI 都可以使用

对于正在构建 AI 应用的开发者来说，理解 MCP 的架构和工作方式是必不可少的技能。接下来的文章将深入讲解如何实现 MCP Server、集成 MCP Client、设计工具调用模式以及生产环境的安全部署。