2_MCP 协议详解：AI 模型与外部系统的标准化连接方案

MCP 是 Anthropic 推出的开放协议，为 LLM 提供了一套标准化的 “ 感知与行动 “ 接口。其核心价值在于：将 AI 从 “ 对话孤岛 “ 升级为可操作真实世界的智能体。

flowchart LR
    subgraph Host["Host (Cursor/Claude)"]
        LLM[LLM]
        Client[MCP Client]
    end
    subgraph Servers["MCP Servers"]
        S1[GitHub Server]
        S2[Search Server]
        S3[Browser Server]
    end
    LLM <--> Client
    Client <-->|JSON-RPC 2.0| S1
    Client <-->|JSON-RPC 2.0| S2
    Client <-->|JSON-RPC 2.0| S3

1. 协议架构与核心机制

1.1 通信协议：JSON-RPC 2.0

MCP 基于 JSON-RPC 2.0 规范构建，所有消息遵循统一格式：

// 请求示例
{"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {...}}
// 响应示例
{"jsonrpc": "2.0", "id": 1, "result": {...}}

Transport 层支持两种模式：

• stdio：本地进程间通信，适用于 Cursor 等桌面应用
• HTTP + SSE：远程服务通信，支持流式响应

1.2 核心组件

MCP 架构由三个主要部分组成：

1. MCP Host (客户端)：发起请求的 AI 应用程序（如 Claude Desktop, IDE, AI Agent）。
2. MCP Server (服务端)：提供数据或工具能力的轻量级服务，通过标准协议暴露接口。
3. Local/Remote Resource：实际被访问的数据源或服务 API。

协议定义了三种主要交互原语：

原语	用途	控制方	示例
Tool	执行操作（动作）	模型决定	search_web(), create_issue()
Resource	提供数据（只读）	用户/应用	file://config.json, db://users
Prompt	预设模板（引导）	用户选择	代码审查模板、翻译模板

设计意图：Tool 让 AI “ 动手 “，Resource 让 AI “ 看见 “，Prompt 让用户 “ 引导 “。

以下展示了 MCP 的典型交互流程：

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#4F46E5', 'primaryTextColor': '#fff', 'primaryBorderColor': '#3730A3', 'lineColor': '#6366F1', 'secondaryColor': '#10B981', 'tertiaryColor': '#F59E0B'}}}%%
flowchart LR
    subgraph Host["Host Application (AI 客户端)"]
        direction TB
        UI["用户界面 (UI)"]
        LLM["LLM 模型"]
        Client["MCP Client SDK"]
    end

    subgraph Transport["传输层"]
        Protocol["JSON-RPC 消息"]
    end

    subgraph Server["MCP Server (服务端)"]
        direction TB
        Logic["业务逻辑 / Router"]
        DB[("数据库 / API / 文件")]
    end

    UI --> Client
    Client <-->|"Stdio / SSE"| Protocol
    Protocol <--> Logic
    Logic <--> DB
    Client <--> LLM

    classDef primary fill:#4F46E5,stroke:#3730A3,color:#fff
    classDef success fill:#10B981,stroke:#059669,color:#fff

    class UI,LLM,Client primary
    class Logic,DB success

1.3 数据交互时序

为了更清晰地理解一次 MCP 请求的生命周期，参考以下时序图：

💡 流程说明: 展示了用户请求如何转化为 MCP Tool 调用并在 Server 端执行的完整链路。

%%{init: {'theme': 'base', 'themeVariables': {'actorBkg': '#4F46E5', 'actorTextColor': '#000', 'actorBorder': '#3730A3', 'signalColor': '#6366F1', 'activationBkgColor': '#E0E7FF', 'activationBorderColor': '#4F46E5'}}}%%
sequenceDiagram
    autonumber
    participant U as "用户"
    participant H as "Host (Claude Desktop)"
    participant S as "MCP Server (GitHub)"
    participant API as "GitHub API"

    U->>H: "查询我的最新 Issue"
    activate H
    H->>H: 路由分析 (Intent Recognition)

    H->>S: 1. call_tool("list_issues")
    activate S
    S->>API: GET /issues
    activate API
    API-->>S: JSON Response
    deactivate API
    S-->>H: Format Result (Text/JSON)
    deactivate S

    H->>H: 生成自然语言回复
    H-->>U: "为您找到以下 Issue..."
    deactivate H

1.4 安全性与部署建议

• 传输层选择：
  • Stdio：适用于本地单机环境（如 Claude Desktop）。Server 作为 Host 的子进程运行，延迟极低。
  • SSE (Server-Sent Events)：适用于分布式部署。当 Server 部署在远程容器或云端时，使用 SSE 进行单向推送，配合 HTTP POST 进行双向通信。
• 权限控制：
  • MCP Server 运行权限取决于启动方式。若通过 stdio 本地运行，通过 Node.js/Python 运行时可能拥有全盘访问权限。
  • 安全最佳实践：务必使用 Sandbox 容器化运行 Server，并严格通过白名单限制其可访问的文件路径或网络域。
• 无状态设计：
  • Server 应设计为 Stateless（无状态）。每次请求应包含执行所需的全部上下文，避免依赖 Server 内存中的会话状态，确保水平扩展能力。

2. 方案对比分析

2.1 MCP Vs. Function Calling

MCP 并非 Function Calling 的替代品，而是其上层封装与标准化。

维度	Function Calling	Model Context Protocol (MCP)
层级	底层引擎 (Engine)	应用协议 (Protocol)
定义方式	每次请求需将临时的 JSON Schema 注入 Prompt	Server 启动时一次性通过协议握手声明 Capabilities (Resources/Prompts/Tools)
连接对象	具体的函数实现	独立的外部服务实体
复用性	低 (代码耦合在应用逻辑中)	高 (Server 可被任一 MCP Client 复用)
适用场景	简单的、紧耦合的逻辑调用	复杂的、模块化的外部系统集成

2.2 MCP Vs. OpenAI GPT Actions

特性	GPT Actions	MCP
生态封闭性	仅限 OpenAI 生态 (ChatGPT/Assistants API)	开放标准 (Claude, Cursor, Local LLMs 均支持)
通信协议	HTTP / REST Only (依赖 OpenAPI Spec)	Stdio (本地管道) + SSE (HTTP)
数据隐私	数据流经 OpenAI 服务器	Local-First (本地直连，无第三方中转)
开发模式	配置式 (YAML/JSON)	编程中心 (TypeScript/Python SDK)

结论：GPT Actions 类似苹果的 Lightning 接口，生态内体验极佳但封闭；MCP 类似 USB-C，强调通用性与本地控制权。

2.3 MCP Vs. RAG (检索增强生成)

MCP 是实现 RAG 的管道之一，而非竞争关系。

• 传统 RAG：应用层自行实现 ETL Pipeline（切片 ->向量化 ->检索），将结果注入 Context。
• MCP RAG：将检索逻辑封装为 MCP Server。应用层（Host）无需关心向量库细节，只需调用 Server 提供的 search_knowledge_base 工具或读取资源。

MCP 使得 “ 知识库 “ 成为一个可插拔的微服务。

3. 开发者指南

3.1 快速上手

目前主流的 MCP 生态平台：

• Smithery: https://smithery.ai/ (类似 Docker Hub 的 MCP 仓库)
• Awesome MCP Servers: https://github.com/punkpeye/awesome-mcp-servers

典型工作流 (以 Cursor 为例)：

1. 用户希望在 Cursor 中直接操作 AWS 资源。
2. 查找并安装 mcp-server-aws。
3. 配置 claude_desktop_config.json 或 Cursor 设置。
4. 在对话框输入 “ 重启我的 EC2 开发机 “，LLM 自动鉴权并执行。

3.2 配置示例

在 claude_desktop_config.json 中添加本地 Server：

{
  "mcpServers": {
    "git-helper": {
      "command": "python",
      "args": ["-m", "mcp_server_git", "--repo-path=/Users/code/project"]
    },
    "postgres-readonly": {
      "command": "npx",
      "args": ["-y", "@mcp/postgres", "postgresql://user:pass@localhost:5432/db"]
    }
  }
}

3.3 GitHub Server 集成

若需让 AI 能够读取私有仓库代码或管理 Issue，可配置官方 GitHub MCP Server：

# 1. 获取 GitHub Personal Access Token (Classic)
# 2. 权限要求：repo (全选), user (read:user)
# 3. 配置文件添加环境变量

"github": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-github"],
  "env": {
    "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxx"
  }
}

4. 总结

MCP 正在成为 AI Agent 时代的 “USB 标准 “。它解决了 LLM 连接外部世界的 “ 最后一公里 “ 问题。对于企业架构师与开发者而言，尽早将内部工具链封装为 MCP Server，是构建 AI Native 基础设施的关键一步。

参考资料

• Model Context Protocol 官方文档
• Smithery - MCP Marketplace
• GitHub - Awesome MCP Servers
• https://www.youtube.com/watch?v=McNRkd5CxFY