08a - MCP 概念入门

本文是《AI Agent 实战手册》第 8 章第 1 节。 上一节：07e-Claude-GPT-Gemini对比 | 下一节：08b-MCP深度架构解析

概述

Model Context Protocol（MCP）是 Anthropic 于 2024 年 11 月发布的开放协议，旨在标准化 AI 应用与外部工具、数据源之间的连接方式。你可以把 MCP 理解为”AI Agent 的 USB 接口”——就像 USB-C 让你的手机、电脑、显示器都能通过同一种接口互联，MCP 让任何 AI 模型都能通过统一协议接入任何外部系统。本节将带你理解 MCP 的核心概念、它为什么存在、以及它的整体架构。

1. MCP 是什么：AI Agent 的 USB 接口

一句话定义

MCP（Model Context Protocol）是一个基于 JSON-RPC 2.0 的开放标准协议，定义了 AI 应用（如聊天机器人、IDE 助手、自定义 Agent）如何发现、连接和调用外部工具与数据源。

USB 类比详解

MCP 的核心价值

在 MCP 出现之前，AI 应用对接外部系统面临经典的 M×N 集成问题：

• M 个 AI 应用（Claude、ChatGPT、Cursor、Kiro……）
• N 个外部系统（GitHub、Slack、数据库、文件系统……）
• 需要 M × N 个定制集成

MCP 将这个问题简化为 M + N：

• 每个 AI 应用只需实现一个 MCP Client
• 每个外部系统只需实现一个 MCP Server
• 总共只需 M + N 个实现

┌─────────────────────────────────────────────────────┐
│              没有 MCP（M×N 问题）                      │
│                                                     │
│  Claude ──定制──→ GitHub                             │
│  Claude ──定制──→ Slack                              │
│  Claude ──定制──→ Database                           │
│  Cursor ──定制──→ GitHub                             │
│  Cursor ──定制──→ Slack                              │
│  Cursor ──定制──→ Database                           │
│  Kiro   ──定制──→ GitHub                             │
│  Kiro   ──定制──→ Slack                              │
│  Kiro   ──定制──→ Database                           │
│                                                     │
│  3 个 AI × 3 个系统 = 9 个定制集成                     │
└─────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────┐
│              有了 MCP（M+N 方案）                      │
│                                                     │
│  Claude ─┐                    ┌─→ GitHub Server      │
│  Cursor ─┼── MCP 协议 ────────┼─→ Slack Server       │
│  Kiro   ─┘                    └─→ Database Server    │
│                                                     │
│  3 个 Client + 3 个 Server = 6 个实现                 │
└─────────────────────────────────────────────────────┘

2. MCP 为什么存在：动机与背景

2.1 AI 模型的”孤岛困境”

即使是最强大的 LLM，也面临三个根本限制：

1. 知识截止：训练数据有时间边界，无法获取实时信息
2. 无法行动：模型只能生成文本，不能直接操作文件、调用 API、查询数据库
3. 上下文有限：无法自动获取项目文件、用户数据等运行时上下文

MCP 的出现正是为了打破这些限制——让 AI 模型能够安全、标准化地”伸出手”触及外部世界。

2.2 行业标准化的需求

OpenAI、Google 等主要 AI 厂商也已采纳 MCP，使其成为事实上的行业标准。

2.3 与 Language Server Protocol 的渊源

MCP 的设计灵感来自 LSP（Language Server Protocol）。LSP 标准化了编程语言工具与 IDE 之间的通信，让一个语言服务器可以服务于 VS Code、Vim、Emacs 等所有编辑器。MCP 用同样的思路，标准化了 AI 应用与外部能力之间的通信。

3. MCP 架构概览

3.1 三层角色模型

MCP 协议定义了三个核心角色：

3.2 通信流程

3.3 传输层

MCP 支持两种主要传输方式：

⚠️ 早期版本使用的 HTTP+SSE（Server-Sent Events）传输方式已在 2025 年被废弃，新项目应使用 Streamable HTTP。

4. MCP 六大核心原语

MCP 定义了六种核心原语（Primitives），分为 Server 端暴露和 Client 端提供两类：

Server 端原语（Server → Client）

4.1 Tools（工具）

作用：Server 暴露给 AI 模型可调用的操作，类似于函数或 API 端点。

特点：

• 每个 Tool 有名称、描述和 JSON Schema 定义的输入参数
• 执行需要用户明确批准（Human-in-the-Loop）
• 模型根据上下文自动选择合适的 Tool

示例场景：查询数据库、创建 GitHub Issue、发送邮件、执行代码

{
  "name": "query_database",
  "description": "执行 SQL 查询并返回结果",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": { "type": "string", "description": "要执行的 SQL 语句" }
    },
    "required": ["sql"]
  }
}

4.2 Resources（资源）

作用：Server 暴露的只读数据，供 AI 模型浏览和引用。

特点：

• 类似于 REST API 中的 GET 端点
• 不执行操作，只提供信息
• 可以是文件内容、API 响应、数据库记录等

示例场景：项目文件列表、配置信息、文档内容、日志数据

4.3 Prompts（提示词模板）

作用：Server 提供的可复用提示词模板，引导 AI 模型的交互方式。

特点：

• 支持参数化（接受动态输入）
• 帮助标准化特定领域的交互模式
• 用户可以从模板列表中选择

示例场景：代码审查模板、SQL 生成模板、文档摘要模板

Client 端原语（Client → Server）

4.4 Sampling（采样）

作用：允许 Server 通过 Client 请求 LLM 生成内容，实现嵌套的 AI 调用。

特点：

• Server 无需自己持有 API Key
• Client 保持对模型访问的控制权
• 支持文本、音频、图像等多模态交互
• 启用 Agent 式行为（在工具执行过程中嵌套 LLM 调用）

4.5 Roots（根目录）

作用：Client 告知 Server 它关注的文件系统根目录或资源范围。

特点：

• 帮助 Server 理解工作上下文
• 限定 Server 的操作范围
• 提高安全性（Server 只能访问指定范围）

4.6 Elicitation（信息征询）

作用：允许 Server 在执行过程中向用户请求额外信息。

特点：

• 2025-06-18 版本新增
• Server 可以在工具执行中途向用户提问
• 支持结构化输入（表单式交互）
• 保持用户对交互流程的控制

原语关系总览

5. MCP 生态现状（2025-2026）

5.1 支持 MCP 的主要 AI 应用

5.2 MCP Server 生态

截至 2025 年底，MCP 生态已拥有数千个开源 Server，覆盖：

• 开发工具：GitHub、GitLab、Jira、Linear
• 数据库：PostgreSQL、MySQL、MongoDB、Redis
• 文件系统：本地文件、Google Drive、S3
• 通信：Slack、Discord、Email
• 浏览器：Puppeteer、Playwright
• 监控：Sentry、Datadog
• 搜索：Brave Search、Tavily

实战案例：5 分钟体验 MCP

以 Claude Desktop 为例，配置一个本地文件系统 MCP Server：

操作步骤

步骤 1：编辑 Claude Desktop 配置文件

打开配置文件（macOS 路径：~/Library/Application Support/Claude/claude_desktop_config.json）：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/yourname/projects"
      ]
    }
  }
}

步骤 2：重启 Claude Desktop

关闭并重新打开 Claude Desktop，它会自动启动配置的 MCP Server。

步骤 3：验证连接

在对话中输入：

请列出我 projects 目录下的所有文件

Claude 会通过 MCP 文件系统 Server 读取目录内容并返回结果。

案例分析

这个简单案例展示了 MCP 的核心工作流：

1. 配置即连接：通过 JSON 配置文件声明 Server，无需编写集成代码
2. 自动发现：Claude 自动发现 Server 提供的 Tools 和 Resources
3. 安全执行：文件操作需要用户确认，保持 Human-in-the-Loop

避坑指南

❌ 常见错误

1. 把 MCP 当成 REST API 替代品

   • 问题：MCP 是有状态的会话协议，不是无状态的 HTTP API
   • 正确做法：理解 MCP 的会话生命周期（initialize → 能力协商 → 交互 → 关闭）

2. 忽略传输层的演进

   • 问题：仍然使用已废弃的 HTTP+SSE 传输方式
   • 正确做法：新项目使用 stdio（本地）或 Streamable HTTP（远程）

3. 跳过能力协商直接调用工具

   • 问题：不同 Server 支持的能力不同，硬编码调用会失败
   • 正确做法：先通过 initialize 和 tools/list 发现可用能力

4. 忽视安全边界

   • 问题：给 MCP Server 过大的权限范围
   • 正确做法：使用 Roots 限定工作范围，遵循最小权限原则

5. 混淆 Tools 和 Resources

   • 问题：把只读数据查询实现为 Tool
   • 正确做法：只读数据用 Resources 暴露，有副作用的操作用 Tools

✅ 最佳实践

1. 从官方 MCP Server 模板开始，不要从零造轮子
2. 本地开发优先使用 stdio 传输，简单且无需网络配置
3. 为每个 Tool 编写清晰的 description，这直接影响 AI 模型的工具选择准确性
4. 关注 MCP 规范版本更新，协议仍在快速演进中
5. 生产环境务必配置 OAuth 2.1 认证（2025-06-18 版本起支持）

相关资源与延伸阅读

参考来源

• Model Context Protocol 官方规范 （2025-03-26）
• MCP 规范 2025-06-18 更新说明 （2025-06）
• MCP 规范 2025-11-25 最新版本 （2025-11-25）
• Developer’s Guide to the Model Context Protocol 2026 （2026-02）
• MCP 实用技术概览 - CodiLime （2025-12）
• MCP 生态完整指南 - DigitalApplied （2025-12）
• MCP 功能指南：Tools, Resources, Prompts, Sampling, Roots, Elicitation - WorkOS （2025-06）
• MCP Streamable HTTP 安全分析 - Auth0 （2025-06）

📖 返回 总览与导航 | 上一节：07e-Claude-GPT-Gemini对比 | 下一节：08b-MCP深度架构解析