MCP 是什么？给开发者的完整指南

看完这篇，你会知道 MCP 解决了什么问题、它怎么运转，以及如何用一个真实 bug 案例理解它的价值。

---

一、你有没有遇到过这种场景

页面有个 bug，筛选功能点了没反应。

你把代码粘给 AI，AI 分析了一番，说「可能是事件绑定的问题」。你改了，没用。AI 又说「可能是异步时序」。你又改了，还是没用。

来回三四次之后，你关掉对话窗口，自己一行行 debug。

AI 不是不聪明，是它根本没看到你的程序在运行时发生了什么。

它只能看代码，看不到：

• 浏览器控制台里有什么报错
• 筛选操作有没有真正发出网络请求
• 请求参数是不是传对了
• 页面 DOM 结构和代码对不上

这是一堵墙。AI 在墙这边，你的运行环境在墙那边。

MCP 就是在这堵墙上开了一扇门。

┌─────────────────────────────────────────────────────────┐
│  没有 MCP                    有了 MCP                    │
│                                                          │
│  AI │墙│ 运行环境         AI ←→ MCP ←→ 运行环境          │
│     │  │                                                 │
│  只能猜代码里的问题        能真正操作浏览器、读日志、查请求  │
└─────────────────────────────────────────────────────────┘

---

二、MCP 到底是什么

MCP（Model Context Protocol） 是 Anthropic 在 2024 年发布的开放协议。

一句话：

MCP 是一套标准，让 AI 能调用外部工具，获取真实世界的信息和操作能力。

注意几个关键词：

• 标准：不是某家公司的私有实现，任何人都可以按规范写工具
• 外部工具：文件系统、数据库、浏览器、API、Git……只要写了对应的 MCP Server，AI 都能用
• 真实世界：不是让 AI 凭代码猜测，而是让它真的去执行、去读数据、去操作界面

MCP 之于 AI 工具，就像 USB 之于外设——接口统一了，工具即插即用。

---

三、没有 MCP 之前有多痛

假设要给 AI 接入三个能力：读文件、查数据库、调 GitHub API。

大概会这样写：

# 每个能力单独定义一套 Function Call 格式
tools = [
    {"name": "read_file",  "parameters": {...}},
    {"name": "query_db",   "parameters": {...}},
    {"name": "github_pr",  "parameters": {...}},
]

# 还要写 dispatch 逻辑，每加一个工具就要改这里
def handle_tool_call(name, args):
    if name == "read_file": ...
    elif name == "query_db": ...
    elif name == "github_pr": ...

问题接踵而来：

• 换个 LLM（Claude → GPT），工具定义格式不同，全部要重写
• 你写的工具，同事没法直接用，各自重复造轮子
• 工具越来越多，dispatch 越来越乱，维护地狱

MCP 解决这些问题的方式很直接：定一套所有人都遵守的格式。
工具按 MCP 标准写一次，任何支持 MCP 的 AI 应用都能用。

---

四、MCP 的三个角色

┌──────────────────────────────────────────────┐
│              Host（宿主应用）                  │
│   VSCode / Claude Desktop / 你自己写的 App    │
│                                              │
│            MCP Client（内置）                 │
│            负责和 Server 通信                 │
└──────────────────┬───────────────────────────┘
                   │  JSON-RPC 协议
         ┌─────────┼──────────┐
         ▼         ▼          ▼
    Playwright   GitHub     数据库
    MCP Server   Server     Server
         │         │          │
      真实浏览器  GitHub API  PostgreSQL

角色	是什么	你需要关心吗
Host	运行 AI 的应用	用现成的即可（VSCode、Claude Desktop）
MCP Client	Host 内置的协议客户端	不需要自己写
MCP Server	对外暴露工具的服务	这是你主要关心的

一次完整调用的过程：

① 你提问
② AI 推理：需要查网络请求
③ AI 输出结构化指令 → { "tool": "browser_network_requests" }
④ Host 通过 MCP Client 发给 Playwright Server
⑤ Server 真正执行，返回结果
⑥ AI 拿到结果，继续推理下一步
↻ 循环，直到任务完成

AI 自己不打开浏览器。 AI 只是"说"要做什么，MCP Server 去真正执行。

---

五、实战案例：用 Playwright MCP 在 VSCode 里调试 bug

场景

前端「出版商筛选」功能点了没反应，用户反馈 bug。

环境准备：

• VSCode + GitHub Copilot（需开通，支持 Agent 模式）
• 前端项目运行在 localhost:3000

---

第一步：配置 Playwright MCP Server

在项目根目录创建 .vscode/mcp.json：

{
  "servers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"],
      "type": "stdio"
    }
  }
}

保存后，文件上方出现 Start 按钮，点击启动。

用命令面板（Ctrl+Shift+P）输入 MCP: List Servers，看到状态为 Running 即成功。

没有 Chrome？加参数切换到 Edge：

"args": ["@playwright/mcp@latest", "--browser", "msedge"]

这个文件可以提交到 Git，团队所有人拉代码后自动获得相同配置，不需要每个人单独配置。

---

第二步：切到 Agent 模式，描述问题

打开 Copilot Chat，输入框下拉选 Agent，然后直接描述：

我的项目运行在 http://localhost:3000
页面右上角有一个「出版商」下拉筛选菜单
选择任意出版商后，下方书籍列表没有变化

请帮我：
1. 打开页面，实际操作筛选菜单，确认 bug 存在
2. 检查有没有控制台报错
3. 检查有没有发出筛选相关的 API 请求
4. 找到原因并修复，修复后再次验证

---

第三步：AI 的完整调试过程

下面是 AI 实际触发的 6 步工具调用——每一步都是真实发生的，不是 AI 在猜。

---

① 打开页面 — browser_navigate

AI 第一步先把页面打开，确认能正常访问，不做任何假设。

调用：browser_navigate
参数：{ "url": "http://localhost:3000" }
返回：{ "status": "success", "title": "书城 | 首页" }

---

② 读取页面结构 — browser_snapshot

AI 看到的不是截图，而是结构化的无障碍元素树，能精确定位每个元素。

返回（元素树片段）：
  combobox "出版商"
    option "人民文学出版社"
    option "中信出版集团"
    option "商务印书馆"

因为是元素树而不是截图，就算页面样式大改，AI 依然能找到正确元素。

---

③ 操作筛选菜单 — browser_click

模拟用户点开下拉菜单，选中「人民文学出版社」，和真实用户操作完全一致，这是复现 bug 的关键一步。

调用 1：browser_click → combobox "出版商"
调用 2：browser_click → option "人民文学出版社"
返回：操作成功

---

④ 查网络请求 — browser_network_requests（关键发现）

选了出版商之后，AI 检查所有网络请求记录：

GET /api/books          ← 初始加载（正常）
（筛选后，无任何新请求）

只有一条初始加载，筛选操作之后没有任何新请求发出。

结论锁定：问题一定在前端逻辑，和后端无关，不用去查 API。

---

⑤ 看控制台 — browser_console_messages

返回：（无任何报错）

没有 JS 报错，说明代码没有崩溃，只是逻辑没走到「发请求」那一步。

范围进一步缩小：事件触发了，但事件处理函数本身有问题。

---

⑥ 定位代码，找到根源

AI 翻查 FilterPanel.vue，找到问题：

// 有问题的代码
onFilter(val) {
  this.filter = val
  // 漏了这一行：
  // this.fetchBooks()
}

onFilter 只更新了本地状态，但忘记调用 fetchBooks() 重新拉数据。

修复后，AI 用 Playwright 再验证一次：

GET /api/books?publisher=人民文学出版社  ← 出现了

筛选请求正常发出，列表正确更新，bug 修复，全程闭环。

---

这个过程里，MCP 做了什么

把上面的流程拆开：

你（自然语言）
  → AI（推理：下一步需要什么工具）
    → Function Call（结构化指令）
      → MCP Client（转发）
        → Playwright MCP Server（真正执行）
          → 真实浏览器
            → 返回结果 → AI 继续推理
              ↻ 循环

MCP 在中间做的三件事：

1. 标准化：AI 输出通用格式，不管底层是 Playwright 还是其他工具，格式一样
2. 隔离：AI 不直接操作浏览器，Server 负责执行，AI 只管思考
3. 可插拔：今天用 Playwright 调浏览器，明天换数据库 Server，AI 的调用方式完全相同

---

六、Playwright MCP 能做什么

工具名	能力
browser_navigate	打开 URL，前进/后退
browser_snapshot	读取页面无障碍结构树
browser_click	点击元素
browser_type	输入文字，填写表单
browser_network_requests	查看所有网络请求记录
browser_console_messages	读取控制台输出
browser_screenshot	截取当前页面

浏览器里人能做的事，AI 通过 Playwright MCP 基本都能做。

---

七、一句话记住 MCP

AI 之前只有大脑，没有手脚和感官。
MCP 给 AI 装上了手脚——操作浏览器、读数据库、调 API。
而且这双手是标准接口，任何工具都能接上去。

---

八、还能接什么

理解了 MCP 的工作方式，你会发现能接的东西远不止浏览器：

MCP Server	AI 获得的能力
@modelcontextprotocol/server-filesystem	读写本地文件
@modelcontextprotocol/server-github	查 PR、Issue、提交记录
@modelcontextprotocol/server-postgres	查询数据库
@playwright/mcp	操作浏览器、截图、读网络请求
你自己写的 Server	任何你想给 AI 的能力

不需要全部从头写，社区已有大量现成的 MCP Server，大多数场景直接拿来用。