MCP 深度解析

MCP” class=”rich_pages wxw-img” data-imgfileid=”100000685″ data-ratio=”0.5625″ src=”https://api.ibos.cn/v4/weapparticle/accesswximg?aid=112789&url=aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9OOVIwZUQza25sazZLOTNQaWJveFZiV0JRVm1RTUlXRTVZdDJMbWVjR2pJTmFnM2J3ampxT1o3aE5rSjg2ZEFYUXVoZFJpYnBWdFVmZ0tNTjBCdlNlYmNRLzY0MD93eF9mbXQ9cG5nJmFtcA==;from=appmsg” data-type=”png” data-w=”960″>

套用一句关于幺半群的名言：”MCP 是一种开放协议，用于标准化应用程序向 LLM 提供上下文的方式，问题何在？”但即使花数小时阅读 MCP 的定义并实操示例，仍难以清晰把握其具体运作流程：LLM 负责什么？MCP 服务器做什么？MCP 客户端的角色是什么？数据流如何流动？决策点位于何处？本文将深入解析 MCP 的本质、工作原理，并通过完整的分步示例展示各组件如何协同工作，以及每一步的具体操作。

具体而言，我们部署了一个故意包含漏洞的 Cloudflare Worker。该错误在 Sentry 中触发警报后，Visual Studio Code（VS Code）内运行的 AI 助手（Cline）通过托管的 Sentry MCP 服务器提取堆栈跟踪信息，通过本地 GitHub MCP 服务器创建对应的 GitHub 问题，修补代码，提交修复并重新部署 —— 所有操作均在人工审批下完成。MCP 将集成工作从 M×N 定制桥接模式简化为 M+N 适配器模式，但也带来了延迟、安全审查和学习曲线等成本。

为何需要 MCP

当 AI 助手需要协调现实系统（如用于监控的 Sentry、代码管理的 GitHub、工单系统 Jira、数据库 Postgres 等）时，每增加一对工具集成，就需要一个定制适配器、一组令牌垫片和一处潜在故障点。最终形成的 “胶水代码” 不仅难以维护，还增加了安全风险。MCP 的诞生旨在通过统一的交互协议取代这种混乱局面，使任何兼容的主机都能直接与合规工具通信。

M×N 集成成本

若没有 MCP，每个大型语言模型（LLM）主机或代理（如 ChatGPT、Claude、Cline 或 VS Code Copilot）与每个工具（如 Sentry、GitHub、Jira、MySQL 或 Stripe）之间都需要独立的连接器 —— 即 M 个主机 ×N 个工具的组合，产生大量胶水代码。每个连接器都需重新实现：

身份验证与令牌刷新
数据格式映射
错误处理与重试机制
速率限制规则
安全强化这导致成本呈二次方增长。可以预见，团队最终只能优先实现少数集成，其余则被归入 “待办事项”。

统一协议管理连接器

MCP 试图为 AI 工具带来类似 USB-C 的统一体验：每个主机只需实现一次 MCP 协议，每个工具只需暴露一个 MCP 服务器，任意主机与工具组合即可通信。复杂度从 M×N 骤降至 M+N。为验证这一设想，我们进行了实际测试。

在进入分步演示前，先快速了解核心概念：

MCP 基础

若您熟悉 LSP（语言服务器协议）或 JSON-RPC，会对 MCP 感到亲切。若不熟悉，以下是 30 秒快速指南：

核心术语


术语	定义	示例	重要性
主机（Host）	运行 LLM 并提供用户界面的应用程序	Claude 桌面版、Cursor、Cline、Windsurf	生成工具调用，协调审批流程
MCP 客户端（MCP Client）	嵌入主机的库	MCP SDK	维护与每个 MCP 服务器的有状态会话
MCP 服务器（MCP Server）	工具前端的轻量级包装器	Sentry MCP、GitHub MCP 服务器	统一暴露工具和资源
工具（Tool）	可调用的函数	list_organizations、create_issue	客户端在运行时可发现；支持类型化 JSON 参数
资源（Resource）	MCP 服务器暴露的文本或二进制对象	PDF 文件、日志文件、查询语法描述、文档	LLM 或用户可访问的信息
传输层（Transport）	客户端与服务器间的数据传输方式	stdio 或 SSE	支持本地或云端；基于 JSON-RPC 2.0 协议

有状态设计

MCP 采用持久连接设计，远程服务器通常使用 HTTP + 服务器发送事件（SSE），本地进程则使用纯 stdio。服务器可记忆每个客户端的上下文（如身份令牌、工作目录、进行中的作业 ID）。这种设计虽比无状态 REST 协议更复杂，但支持流式差异更新、长运行作业和服务器发起的回调。

发现流程

客户端调用tools/list询问服务器：”你能做什么？”
服务器返回 JSON 数据，描述每个工具的名称、摘要及参数和结果的 JSON Schema。
主机将该 JSON 注入模型上下文。
当用户提示需要执行操作时，模型生成结构化调用：

ounter(line{  "name": "create_issue",  "arguments": { "title": "...", "body": "..." }}

MCP 客户端通过传输层执行调用，并将结果分块流回。对话随后继续。

演示场景：下午 5 点的回归警报噩梦

为便于理解，设想如下场景：周五下午，你是办公室最后一人，正当收拾行李时，Slack 突然警报称worker.ts:12出现新的回归错误。我们希望找到从第一条 Slack 消息到部署修复的最短路径。

演示组件


组件	角色
Cloudflare Worker（bug-demo）	每次请求触发 TypeError，并通过 Sentry SDK 向 Sentry 报告
Sentry MCP（托管）	工具：list_issues；使用 SSE 传输 + OAuth 认证
GitHub MCP（本地）	工具：list_issues、create_issue、add_issue_comment、create_pull_request（通过 Docker 运行）；使用 stdio 传输 + API 密钥
Cline（VS Code 插件）	MCP 主机、代理、代码编辑器及人工审批网关，连接至两个 MCP 服务器

漏洞百出的 Cloudflare Worker 向 Sentry 报告异常，通过托管的 Sentry MCP（SSE）传递至 VS Code 内的 Cline。同一会话随后连接至本地运行的 GitHub MCP（stdio），允许代理在人工监督下创建问题、添加评论并推送拉取请求至 GitHub 仓库。

搭建流程

环境要求


要求	版本 / 详情	用途
Node	≥ 18	构建 Worker 并运行 npx 工具
Docker	最新桌面版	本地运行 GitHub MCP 服务器
VS Code	最新桌面版	代码编辑器
Cline	最新版本	MCP 主机 / 代理
Sentry 账户	免费套餐即可	捕获崩溃日志
GitHub 账户	任意套餐	为 MCP 服务器生成访问令牌
Cloudflare 账户	免费套餐即可	托管漏洞代码
LLM	需支持 Cline（本演示使用 Mistral Codestral 25.01）	运行 Cline 代理

初始化漏洞 Worker

在终端执行：

ounter(linenpx -y wrangler init bug-demo

按提示选择：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line╭ Create an application with Cloudflare Step 1 of 3│├ In which directory do you want to create your application?│ dir ./bug-demo│├ What would you like to start with?│ category Hello World example│├ Which template would you like to use?│ type Worker only│├ Which language do you want to use?│ lang TypeScript│├ Copying template files│ files copied to project directory│├ Updating name in `package.json`│ updated `package.json`│├ Installing dependencies│ installed via `npm install`│╰ Application created
╭ Configuring your application for Cloudflare Step 2 of 3│├ Installing wrangler A command line tool for building Cloudflare Workers│ installed via `npm install wrangler --save-dev`│├ Installing @cloudflare/workers-types│ installed via npm│├ Adding latest types to `tsconfig.json`│ added @cloudflare/workers-types/2023-07-01│├ Retrieving current workerd compatibility date│ compatibility date 2025-04-26│├ Do you want to use git for version control?│ yes git│├ Initializing git repo│ initialized git│├ Committing new files│ git commit│╰ Application configured
╭ Deploy with Cloudflare Step 3 of 3│├ Do you want to deploy your application?│ no deploy via `npm run deploy`│╰ Done

进入项目目录：

ounter(linecd bug-demo

安装 Sentry SDK：

ounter(linenpm install @sentry/cloudflare --save

在 VS Code 中打开项目：

ounter(linecode .

编辑wrangler.jsonc，添加compatibility_flags数组：

ounter(line"compatibility_flags": [  "nodejs_compat"]

访问Cloudflare Worker 的 Sentry 设置指南，复制示例代码至src/index.ts，并在fetch()方法中添加故意漏洞：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line// !mark(10:11)import * as Sentry from "@sentry/cloudflare";
export default Sentry.withSentry(  (env) => ({    dsn: "https://[SENTRY_KEY]@[SENTRY_HOSTNAME].ingest.us.sentry.io/[SENTRY_PROJECT_ID]",    tracesSampleRate: 1.0,  }),  {    async fetch(request, env, ctx) {      // ❌ intentional bug      undefined.call();      return new Response("Hello World!");    },  } satisfies ExportedHandler<Env>,);

部署并触发漏洞：

ounter(linenpm run deploy

在浏览器访问 Cloudflare Worker 地址

ounter(linehttps://bug-demo.<your-cf-hostname>.workers.dev

应看到错误：

ounter(line错误1101 - Worker抛出异常Error

在 Cline 中配置 Sentry MCP 服务器

在 VS Code 中安装 Cline 后，执行以下步骤：

点击侧边栏的 Cline 图标。
点击 Cline 面板顶部的 “MCP Servers” 按钮。
选择 “Installed” 标签页。
点击 “Configure MCP Servers”。
粘贴以下 Sentry MCP 服务器配置 JSON 并保存（Cmd + S）：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line{  "mcpServers": {    "sentry": {      "command": "npx",      "args": ["-y", "mcp-remote", "https://mcp.sentry.dev/sse"]    }  }}

保存后浏览器将弹出授权窗口，点击 “Approve” 允许 Remote MCP 访问 Sentry 账户。

在 Cline 中配置 GitHub MCP 服务器

生成 GitHub 个人访问令牌：

在 GitHub 中点击头像，进入设置。
左侧栏选择 “Developer settings” → “Personal access tokens” → “Fine-grained tokens”。
点击 “Generate new token”，输入名称，选择 “All repositories”，权限勾选：

Administration: Read and Write
Contents: Read and Write
Issues: Read and Write
Pull requests: Read and Write

生成令牌并保存。

在 Cline 中添加 GitHub MCP 服务器：

重复配置 Sentry MCP 的步骤 1-4。
粘贴以下配置 JSON（替换<YOUR_TOKEN>为实际令牌）：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line{  "mcpServers": {    "sentry": {...},    "github": {      "command": "docker",      "args": [        "run",        "-i",        "--rm",        "-e",        "GITHUB_PERSONAL_ACCESS_TOKEN",        "ghcr.io/github/github-mcp-server"      ],      "env": {        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"      }    }  }}

保存并点击 “Done”。

实战演示：创建 GitHub 仓库

向 Cline 提问：”创建一个名为 bug-demo 的私有 GitHub 仓库”。

流程解析：

系统提示与工具调用Cline 向 LLM 发送包含提示、工具列表及模式的请求（提示构建逻辑见Cline 仓库 src/core/prompts/system.ts）。
LLM 生成工具调用LLM 生成结构化工具调用（XML 格式）：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line<use_mcp_tool>  <server_name>github</server_name>  <tool_name>create_repository</tool_name>  <arguments>  {    "name": "bug-demo",    "private": true  }  </arguments></use_mcp_tool>

Cline 发送调用至 MCP 服务器通过 stdio 传输发送 JSON-RPC 请求：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line{  "jsonrpc": "2.0",  "id": "42",  "method": "create_repository",  "params": {    "name": "bug-demo",    "private": true  }}

GitHub MCP 服务器处理请求调用 GitHub API 创建仓库，返回结果：

ounter(line{  "jsonrpc": "2.0",  "id": "42",  "result": {    "id": 123456789,    "name": "bug-demo",    "visibility": "private",    "default_branch": "main",    "git_url": "git://github.com/speakeasy/bug-demo.git",    "etc": "..."  }}

Cline 展示结果并推送仓库结果显示在 UI 中，并通过 git 命令推送至 GitHub：

ounter(linegit remote add origin git@github.com:speakeasy/bug-demo.git && git push -u origin main

使用 MCP 修复漏洞

向 Cline 下达任务：

从 Sentry 获取最新问题。
创建 GitHub 问题并关联 Sentry 链接。
根据 Sentry 问题修复漏洞。
在新分支提交变更，引用两个问题。
推送分支至 GitHub。
打开拉取请求（PR）。

关键步骤：

获取 Sentry 问题Cline 调用 Sentry MCP 的list_issues工具，获取最新错误详情（包含堆栈跟踪）：

ounter(line{  "jsonrpc": "2.0",  "id": "42",  "method": "list_issues",  "params": { "sortBy": "last_seen" }}

响应显示漏洞位于src/index.ts第 12 行的undefined.call()。

创建 GitHub 问题调用 GitHub MCP 的create_issue工具：

ounter(line{  "jsonrpc": "2.0",  "id": "44",  "method": "create_issue",  "params": {    "owner": "speakeasy",    "repo": "bug-demo",    "title": "Fix bug in index.ts",    "body": "关联Sentry问题：https://speakeasy.sentry.io/issues/NODE-CLOUDFLARE-WORKERS-1"  }}

代码修复与提交

LLM 通过read_file工具读取代码，生成修复方案（删除undefined.call()）。
Cline 创建分支、提交变更并推送：

ounter(linegit checkout -b fix-bug-NODE-CLOUDFLARE-WORKERS-1  git add src/index.ts && git commit -m "Fixes NODE-CLOUDFLARE-WORKERS-1 and closes #1"  git push origin fix-bug-NODE-CLOUDFLARE-WORKERS-1

创建拉取请求调用create_pull_request工具合并分支：

ounter(line{  "jsonrpc": "2.0",  "id": "47",  "method": "create_pull_request",  "params": {    "owner": "speakeasy",    "repo": "bug-demo",    "title": "Fix bug in index.ts",    "head": "fix-bug-NODE-CLOUDFLARE-WORKERS-1",    "base": "main",    "body": "修复Sentry问题并关闭#1"  }}

人工审批与部署开发者审核 PR 并合并，重新部署 Worker：

ounter(linenpm run deploy

验证发现漏洞已修复，Sentry 不再报告新错误。

经验总结

优势：协议统一化

MCP 兑现了其承诺：只需为每个服务配置一次，而非构建两两之间的定制桥接。以包含三个组件（Cline 主机、Sentry 服务器、GitHub 服务器）的演示为例：


集成方式	所需连接数
直接 API（M×N）	3×2=6
MCP（M+N）	3+2=5
当组件扩展至 10 个主机和 10 个工具时，MCP 仅需 20 个适配器，而传统方式需 100 个。
此外，JSON Schema 系统提升了工具可发现性：Cline 连接服务器时自动获取完整操作文档，无需查阅外部 API 参考。

挑战：延迟、安全与学习曲线

延迟MCP 在 LLM 与 API 间引入额外层，导致轻微延迟。尽管对多数场景影响可忽略，但在延迟敏感型应用或复杂工作流中需谨慎评估。
安全

令牌管理：不同服务器需独立认证（如 Sentry 的 OAuth、GitHub 的 API 令牌）。
权限范围：用户需为每个服务器单独授权，流程繁琐。
令牌刷新：支持 OAuth 刷新的客户端较少，当前依赖mcp-remote等包装器处理。

学习曲线

文档不足：规范虽全面，但实用指南有限。

{{userData.name}}已认证

MCP 深度解析