DevPawDEVPAW · GROUND-UP DEV NOTES
搜索
菜单
ZH-HANS
한국어English日本語繁體中文EspañolPortuguês简体中文
AI 编程与智能体

[MCP·Skill #1] 什么是 MCP 服务器？从连接方法到安全注意事项

使用 ChatGPT 或 Claude 时，总会有些不尽如人意的时刻。模型很聪明，却看不到我的数据库，也读不了公司内部 Wiki。

6 分钟阅读
[MCP·Skill #1] 什么是 MCP 服务器？从连接方法到安全注意事项 封面图

使用 ChatGPT 或 Claude 时，总会有些不尽如人意的时刻。模型很聪明，却看不到我的数据库，也读不了公司内部 Wiki。

因此，大家开始直接连接 API。但不同模型和工具的集成方式各不相同，组合越多，集成代码就会呈指数增长。

MCP（Model Context Protocol）就是为了解决这个问题而出现的标准。简单来说，它是将外部工具和数据接入 AI 模型的通用规范，常被称为“AI 界的 USB-C”。

本文将介绍 MCP 究竟解决了什么问题、采用前后的集成工作有何变化、它的内部结构与 function calling 有何不同，以及现在值得立即接入的代表性服务器。

先从核心摘要开始。

  1. MCP 是连接 AI 与外部工具的开放标准协议（由 Anthropic 于 2024 年 11 月发布）。
  2. 直接集成需要数百行代码的工作，有了 MCP 服务器后只需几行配置即可完成。
  3. 它并不替代 function calling，而是在其之上标准化并复用工具的一层。
  4. 随着 OpenAI 和 Google 也采用它，MCP 实际上已成为行业标准，服务器生态正在快速发展。

MCP 解决的问题：M×N 集成地狱

先看看 MCP 出现之前的情况。

如果有 M 个 AI 应用和 N 个要连接的工具，就需要 M×N 份集成代码。Claude、ChatGPT 和 Cursor 的 GitHub 集成都必须分别开发。

MCP 在两者之间加入了标准规范。工具端只需创建一次 MCP 服务器，AI 应用端只需实现一次 MCP 客户端。M×N 变成 M+N。

想想 USB-C 出现以前，每台设备都要携带不同充电线的日子就明白了。MCP 统一的就是这套线缆规范。

不过，只看 M+N 之类的公式，可能还难以直观感受差异。用两种方式实现同一个功能，区别就会很明显。

同一功能：采用前后对比

假设我们要构建“一个查询 GitHub issue 并回答问题的 AI”。

在 MCP 之前，以下工作都由你负责。

  1. 定义工具 schema：直接以 JSON schema 编写“list_issues 接收 owner、repo 和 state”。
  2. 编写实际调用代码：GitHub REST API 客户端、令牌管理和分页处理。
  3. 实现执行循环：模型调用工具后接收结果，再返回给模型的往返代码。
  4. 在每个应用中重复上述工作：Claude 集成一份，公司内部聊天机器人再一份。

仅查询 issue，加上样板代码就要数百行；每增加一个工具，都要重复 1～3 次。

有了 MCP，只需这样就结束了。

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

schema、API 调用、身份验证和错误处理都已内置在服务器中。你只需注册服务器，然后说：“总结这个仓库最近的 bug issue。”

项目 直接集成 使用 MCP 服务器
编写代码 schema、调用和循环共数百行 5 行配置
身份验证与错误处理 自行实现 内置于服务器
添加其他 AI 应用 从头重做 复用同一服务器
添加工具 修改代码并重新部署 只需更新服务器

最后一行尤其重要。即使服务器新增功能，你这边的代码也一行不用改，这就是标准化的力量。

内部结构：主机、客户端和服务器

MCP 有三个角色。

组件 作用 示例
主机 用户使用的 AI 应用 Claude Desktop, Cursor
客户端 在主机内与服务器进行一对一通信 内置于主机
服务器 公开工具和数据的程序 GitHub 服务器、数据库服务器

一个主机可以启动多个客户端，每个客户端连接一个服务器。通信规范是 JSON-RPC 2.0；本地进程使用 stdio，远程连接使用 HTTP 流式传输。

主机内的客户端与服务器进行一对一连接。
主机内的客户端与服务器进行一对一连接。

服务器公开的功能分为三类。

  • 工具（tools）：模型调用的函数，例如“创建 issue”和“执行查询”。
  • 资源（resources）：模型读取的数据，例如文件内容和数据库 schema。
  • 提示（prompts）：服务器预先准备的提示模板。

关键在于运行时查询工具列表。客户端连接服务器后会问“你能做什么？”，服务器则返回工具列表和 schema。这就是服务器更新后代码仍能保持不变的原因。

它和 function calling 有什么不同？

读到这里，你可能会问：“这不是早就能用 function calling 做到了吗？”

它们处于不同层级。function calling 是与模型对话的规范：“模型，这些函数可用，需要时请以调用格式回复。”函数如何实现、从哪里获取，完全由开发者负责。

MCP 是发布和复用这些函数的规范。它将工具实现、身份验证和文档打包成服务器，让任何 AI 应用都能接入使用。

如果说 function calling 是“函数调用语法”，MCP 就是“包含函数的库生态”。实际上，MCP 客户端在内部直接使用 function calling。两者不是替代关系，而是上下层关系。

因此，“function calling 和 MCP 该用哪个？”这个问题本身并不成立。只在一个应用中使用几个函数时，直接实现 function calling 就够了；如果要在多个应用中复用，或使用别人创建的工具，就应该选择 MCP。

现在值得立即接入的代表性服务器

生态发展迅速，大多数常用工具都已经有对应服务器。这里挑出五个反响较好的选项。

服务器 可以做什么
Playwright AI 直接操作浏览器：点击、输入、截图
Figma 读取设计稿并转换为前端代码
Notion 搜索和整理文档、会议纪要，并创建页面
GitHub 查询和创建 issue、PR，并搜索代码
Supabase(Postgres) 使用自然语言查询数据库并了解 schema

如果只能选一个，我会选 Playwright。接入后试着说：“进入这个网站，填写注册表单并截图。”看到 AI 打开浏览器，实际点击和输入后，就不需要再解释为什么连接工具会改变游戏规则了。它还可以直接用于 E2E 测试自动化和重复性网页任务。

对于前端开发者来说，Figma 也非常有感。过去需要看着设计稿手动转换为标记的工作，会变成让能够直接读取设计稿的 AI 完成：“把这个 frame 做成 React 组件。”

只需在配置文件中写几行，连接就完成了。
只需在配置文件中写几行，连接就完成了。

注意事项与局限

它并非万能。下面也看看实际工作中需要注意的问题。

首先是安全性。MCP 服务器是向模型授予执行权限的通道，因此接入不可信的服务器可能因提示注入而导致数据泄露。最安全的做法是只使用官方注册表或经过验证的服务器。

还存在上下文成本。连接的服务器越多，工具定义占用的上下文窗口就越大，反而可能降低模型性能。正如表格所示，最好只连接当前需要的工具。

总结

MCP 并不是让“模型变得更聪明”的技术，而是将“模型能够触及的范围”标准化。把直接集成需要数百行代码的工作变成几行配置，并建立一个可以直接接入他人创建的工具生态，这两点才是本质。

下一篇文章将整理经常与 MCP 比较的 Claude Code Skill 和子代理分别扮演什么角色。

延伸阅读