MCP：从使用到原理

一、为什么会出现 MCP

先想象一个没有 MCP 的世界

你在开发一个 AI 应用，用到了三个功能：

1. 读写本地文件
2. 查 GitHub Issues
3. 在 Slack 发消息

在没有 MCP 之前，你需要：

• 分别给每个 AI 应用单独集成文件 API、GitHub API、Slack API。
• Claude Desktop 要集成一遍，VS Code 要再集成一遍，自己的应用还要再集成一遍。
• 每个 AI 框架的工具注册格式都不一样，换一个框架就要重写一遍对接代码。

因为没有统一标准，所以每次都要重复造轮子，效率极低。

MCP 的出现

2024 年底，Anthropic 发布了 MCP（Model Context Protocol，模型上下文协议）。

它的目标就一个：让 AI 应用访问外部工具和数据的方式标准化，一次实现、到处可用。

一个形象的类比：MCP 之于 AI 工具，就像 USB-C 之于充电线。

以前每款手机用不同接口，充电器不通用。USB-C 出来之后，一根线走天下。
MCP 做的事情类似——不管你用哪个 AI 客户端（Claude、VS Code、Cursor……），只要服务器实现了 MCP 协议，就可以直接接入。

二、MCP 的整体架构

MCP 的架构分三层：

┌──────────────────────────────────────┐
│          MCP Host（宿主应用）          │
│   Claude Desktop / VS Code / Cursor  │
│   包含一个或多个 MCP Client            │
└─────────────────┬────────────────────┘
                  │ MCP 协议
        ┌─────────┼─────────┐
        ▼         ▼         ▼
   MCP Server  MCP Server  MCP Server
   （文件系统） （GitHub）  （数据库）

MCP Host（宿主）

承载 AI 对话的应用程序，负责：

• 管理多个 MCP Client 的生命周期
• 在 AI 和 MCP Server 之间传递消息
• 控制 MCP Server 的权限

例如：Claude Desktop、VS Code（GitHub Copilot）、Cursor、Windsurf。

MCP Client

宿主内部的连接器，每个 Client 对应一个 MCP Server。它负责：

• 建立并维护与 Server 的连接
• 代表 AI 向 Server 发送请求
• 接收 Server 的响应

一个宿主可以有多个 Client，分别连接不同的 Server。

MCP Server

提供具体能力的服务，可以是：

• 本地进程（读文件、运行命令）
• 远程服务（查 GitHub、发邮件）

每个 Server 暴露三类东西（后面详细讲）：Tools、Resources、Prompts。

三、MCP Server 能提供三类能力

1. Tools（工具）—— 模型能主动调用的函数

就是上篇讲的 Tool，但通过 MCP 协议暴露出来。

工具示例：
- read_file(path)     → 读取文件内容
- create_issue(...)   → 在 GitHub 创建 Issue
- send_message(...)   → 在 Slack 发消息
- run_query(sql)      → 执行 SQL 查询

特点：由模型主动决定是否调用，类似"动词"。

2. Resources（资源）—— 宿主可以读取的数据

Resources 是数据源，不是函数。模型可以通过宿主读取这些数据作为 Context。

资源示例：
- file:///home/user/document.pdf   → 本地文件
- postgres://db/customers          → 数据库内容
- github://repo/README.md          → 仓库文件

特点：像"名词"，是只读数据；由宿主/用户决定要不要加载进来。

3. Prompts（提示模板）—— 可复用的对话模板

预制好的 Prompt 模板，可以带参数动态填充。

模板示例：
- code_review(language, code) → 生成代码审查 Prompt
- summarize(style, text)      → 生成摘要 Prompt
- debug_error(error, context) → 生成调试分析 Prompt

特点：像"短语模板"，让用户快速启动特定任务。

四、怎么使用 MCP（实操）

在 Claude Desktop 里接入 MCP Server

Claude Desktop 的 MCP 配置文件路径：

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

以接入"文件系统 MCP Server"为例，配置如下：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/你的用户名/Documents"
      ]
    }
  }
}

重启 Claude Desktop，你就能让 Claude 读写 /Documents 目录里的文件了。

在 VS Code（GitHub Copilot）里接入 MCP Server

VS Code 1.99+ 支持 MCP，在 .vscode/mcp.json 或用户设置里配置：

{
  "inputs": [],
  "servers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}"
      }
    }
  }
}

常用的公开 MCP Server

社区已经有大量现成的 MCP Server，直接用 npm/pip 安装：

MCP Server	功能
@modelcontextprotocol/server-filesystem	读写本地文件
@modelcontextprotocol/server-github	查询 Issues、PR、仓库
@modelcontextprotocol/server-postgres	执行 PostgreSQL 查询
@modelcontextprotocol/server-brave-search	Brave 搜索引擎
@modelcontextprotocol/server-sentry	查询 Sentry 错误
mcp-server-sqlite	SQLite 数据库

官方列表：modelcontextprotocol.io/servers

五、底层原理：MCP 是怎么"跑"的

传输协议：两种模式

Stdio（标准输入输出）—— 本地进程

Host/Client ←→ stdin/stdout ←→ MCP Server（本地进程）

适合本地工具（文件系统、本地数据库）。Client 启动 Server 进程，通过标准 I/O 通信。

Streamable HTTP —— 远程服务

Host/Client ←→ HTTP/SSE ←→ MCP Server（远程服务器）

适合云端服务（GitHub、Slack、第三方 API）。支持 OAuth 认证，可以长连接推送。

消息格式：JSON-RPC 2.0

MCP 的所有通信用 JSON-RPC 2.0 格式，结构很简单：

请求：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "read_file",
    "arguments": { "path": "/tmp/test.txt" }
  }
}

响应：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [{ "type": "text", "text": "Hello World" }]
  }
}

生命周期：从连接到调用

第 1 阶段：初始化握手（initialize）

Client 连接 Server 后，先交换能力列表：

• Client 说"我支持这些功能"
• Server 说"我能提供这些功能"
• 双方确认协议版本

第 2 阶段：发现能力（tools/list）

Client 问"你有哪些工具？"，Server 返回工具列表（名称 + 说明书）。

第 3 阶段：执行调用（tools/call）

AI 需要某个工具时，Client 代为发送调用请求，Server 执行并返回结果。

第 4 阶段：变化通知（notifications/tools/list_changed）

Server 的工具列表发生变化时，可以主动通知 Client 刷新——这样你在 Server 端新增工具后，Host 无需重启就能立刻用上。

Client                    Server
  │── initialize ──────────▶│
  │◀─ capabilities ─────────│
  │── tools/list ───────────▶│
  │◀─ [{name,description}] ─│
  │── tools/call ───────────▶│  （AI 发起调用时）
  │◀─ result ───────────────│
  │◀─ notifications/... ────│  （工具列表变更时）

六、MCP vs Tool：有什么区别

很多人会混淆 MCP 和 Tool，下面对比清楚：

维度	Tool（原始机制）	MCP（标准化协议）
本质	函数 + JSON Schema	一套通信标准
谁实现	应用开发者自己写	任何人都可以发布 MCP Server
复用性	和 AI 框架绑定	框架无关，到处可用
更新方式	改代码重新部署	Server 热通知，无需重启
除了工具	只有 Tools	还有 Resources 和 Prompts

总结：Tool 是"一块砖"，MCP 是"标准砖厂 + 搬运规范"。

七、MCP vs Agent Skill：同是"技能"，为何不同

这两个概念经常让人困惑，详细对比见 Agent Skill从使用到原理，简单说：

• MCP 是一个技术标准，让 AI 连接外部服务和工具。
• Agent Skill 是一份"说明书"（SKILL.md），教 AI 怎么处理某类任务的知识和流程。
• MCP 解决"我能连哪些服务"，Skill 解决"我该怎么做事"。

八、小结

• MCP 出现的原因：工具集成没有标准，重复建设严重。
• 架构：Host → Client → Server 三层，Server 暴露 Tools / Resources / Prompts。
• 两种传输：Stdio（本地进程）和 Streamable HTTP（远程服务）。
• 通信格式：JSON-RPC 2.0，有完整的生命周期（初始化 → 发现 → 调用 → 通知）。
• 本质价值：一套标准 = 一次实现、到处可用，极大降低 AI 与外部世界连接的成本。

理解了 MCP，你就明白了 AI 工具生态的"底层配线"。再往上走一步——当 AI 有了 MCP 工具集、还有了记忆和自主循环能力，它就成为了一个 Agent。