MCP：从原理、源码、实战到企业落地，一篇彻底讲透 AI 世界的标准协议

MCP：从原理、源码、实战到企业落地，一篇彻底讲透 AI 世界的标准协议

如果你最近关注过 AI 应用开发，大概率已经听过 MCP 这个名字。但讲真，市面上聊 MCP 的文章不少，能把原理、实战、复盘和企业落地串在一起讲透的，确实不多。这篇文章打算换一种方式——从“为什么需要 MCP”开始，一路走到“怎么写出规范的 MCP Server”，中途还会拿一个真实的项目做一次复盘，最后落到企业级场景里该怎么用。篇幅不短，但值得读完。

第一部分：认知（为什么）

1 为什么 MCP 会突然火起来？

先不讲 MCP，讲历史。

最早，LLM 只会“续写文本”，靠 Prompt 引导输出；后来发现可以让模型“决定调用哪个函数”，出现了 Function Calling；Function Calling 演化出更通用的 Tool Calling，模型可以调用任意结构化定义的工具；各家平台开始做 Plugin 生态，试图让工具可插拔、可复用。

随着 Agent——能自主规划、多轮调用工具的应用——成为主流范式，“工具怎么统一接入”这个问题被无限放大。每个 Agent 框架都在重新发明一遍工具接入层。MCP 就是在这个节点上出现的：它不是一次突发奇想，而是 Agent 发展到这个阶段的必然产物。

2 MCP 到底解决了什么问题？

一句话说清楚：如果你写过 Agent，大概率经历过这几件事：想让 Agent 查一下 GitHub issue，接一遍 GitHub SDK；想操作 Docker，再接一遍 Docker SDK；想查数据库，再写一套 MySQL 连接和权限逻辑。换一个 Agent 框架，前面的活儿全部重来一遍。

有了 MCP 之后，Agent 只依赖 MCP 协议本身，不关心背后是 GitHub 还是别的什么系统。任何 Agent——无论 Claude Desktop、OpenClaw、Hermes 还是自研 Agent——都能接入任何 MCP Server，真正做到 Plug & Play。

3 MCP 和 Function Calling 有什么区别？

这是最容易混淆的一对概念。Function Calling 是模型能力层面的机制：给模型一份函数签名（JSON Schema），模型根据当前对话决定要不要调用、调用哪个、传什么参数。这套机制是模型自己实现的能力，OpenAI、Anthropic、Google 各家的 Function Calling 接口格式都不完全一样。

但 Function Calling 本身不规定：这个“函数”部署在哪、怎么被发现、怎么跨应用复用、怎么鉴权。同一个函数定义，换一个模型或框架，往往要重新写一遍接入代码——这正是前面那种“if/else 耦合”问题的根源。

MCP 是在 Function Calling 之上，补齐了“传输层 + 发现层 + 生态层”：统一的协议格式、统一的 Server 部署方式，让“工具”可以脱离具体某个 Agent 框架独立存在，被任意支持 MCP 的模型或 Agent 发现和调用。

4 MCP 和 OpenAPI 有什么关系？

几乎每个懂后端的读者看到 MCP 的第一反应都是：这不就是 OpenAPI 换个皮吗？

其实不是。OpenAPI 文档写得再详细，也是假设“调用方是一个懂 HTTP、能解析 JSON Schema、按文档一步步编码接入的程序员或程序”。而 LLM 面对一份几百个字段的 OpenAPI 文档时，既没法像人一样理解语境，也没法像程序一样按类型系统硬编码——它需要的是一份为决策而生的描述：这个工具是干什么的、什么时候该用、传什么参数、会有什么副作用。这正是 MCP 里 Tool 的 Description 存在的意义。

所以准确的说法不是“MCP 取代 OpenAPI”，而是：MCP 是在 OpenAPI 描述的能力之上，重新长出的一层“给 AI 看的接口层”。

5 为什么说 MCP 是 AI 世界的 USB？

先看看历史上已经存在的这些“标准”，各自解决的是什么问题：

协议/规范	解决的问题	面向对象
REST	资源的增删改查如何通过 HTTP 表达	程序调程序
GraphQL	客户端如何按需查询数据，减少冗余字段	程序调程序
gRPC	高性能、强类型的跨服务调用	服务调服务
OpenAPI	如何描述一个 REST API 的结构，方便生成文档/客户端	人/工具链
JSON-RPC	如何用 JSON 表达一次远程过程调用	程序调程序
MCP	LLM 如何发现、理解、调用外部能力	AI 调工具

前面几个协议标准化的都是“接口怎么描述、怎么传输”，服务对象始终是程序或人。而 MCP 标准化的是完全不同的东西——它填补的是一个真空地带，而不是在已有赛道里抢生意，这正是 MCP 能在短时间内被 Claude、OpenAI、Gemini 同时接纳的根本原因。

用 USB 类比最直观：不管外设是什么品牌，只要遵循 USB 标准，电脑就能识别、能用。MCP 也一样——不管后端是什么系统，只要遵循 MCP 协议封装，任何 Agent 都能接入。

第二部分：原理（是什么）

6 MCP 整体架构

这是全网最容易画错的一张图——很多文章把 Client 和 Server 的边界画错，或者漏掉了谁负责调用 LLM 这一层。

核心架构很清晰：用户面对 Agent 应用，Agent 内部嵌着 MCP Client，Client 通过 MCP 协议（stdio 或 HTTP）与 MCP Server 通信。Server 内部则负责把协议请求翻译成对具体业务 API 的调用，并暴露 Tool、Resource、Prompt 三类能力。

7 MCP Client 与 Server

MCP Client 内嵌在 Agent 应用里（比如 Claude Desktop、OpenClaw 本身自带 Client），负责发起协议请求。MCP Server 是你写的那部分，负责翻译——把协议请求翻译成对具体业务 API 的调用。Client 和 Server 之间只认 MCP 协议，互不关心对方内部怎么实现，这就是解耦的关键。

也正因为这样的职责划分：MCP Server 不生产能力，只做翻译——把已有系统的能力（REST API、数据库、命令行工具……）翻译成 LLM 能理解、能决策调用的结构化描述。

8 MCP Tool

Tool 是 MCP 里最高频使用的能力。这里先建立一个认知：LLM 根本不会读你的实现代码，它决策时只能看到三样东西：Tool Name（工具名）、Description（描述）、InputSchema（输入参数结构）。

这决定了 Description 和 Schema 的质量，直接影响 Tool 会不会被正确调用——第四部分会用真实代码展开细讲。

9 MCP Resource

除了“可调用的工具”，MCP Server 还可以暴露可读取的资源（比如一份文件、一段日志、一张配置表）。Resource 和 Tool 的区别在于：Tool 是“让 LLM 主动执行一个动作”，Resource 是“直接把一段内容提供给 LLM 读取”，不需要经过一次调用决策。适合暴露那些“读多改少、上下文本身就该带上”的内容。

10 MCP Prompt

Server 还可以预置一些提示词模板，供 Client 端直接复用。比如一个代码审查类的 MCP Server，可以内置一个审查该 PR 的标准 Prompt 模板，减少 Agent 自己重新设计 Prompt 的成本，也保证团队内 Prompt 风格的一致性。

11 Sampling

这是更进阶的能力，允许 MCP Server 反过来向 Client 请求“帮我调用一次 LLM 采样”。适用于 Server 内部本身也需要 AI 能力辅助决策的场景——比如一个日志分析 MCP Server，在处理某个 Tool 调用的过程中，可能需要临时借助 LLM 做一次归纳，这时就可以通过 Sampling 反向请求 Client 侧的模型能力，而不用自己额外接一套 LLM API Key。

大部分教程只讲 Tool，是因为 Tool 确实是最高频、最核心的能力，但理解 Resource / Prompt / Sampling 能让你知道：MCP 不只是“工具调用协议”，它是一整套“AI 与外部世界交互”的协议族。

12 一次完整调用流程

把 initialize、list_tools、call_tool 串起来看一次完整的会话生命周期：先是握手初始化，然后 Client 拉取工具清单，随后 LLM 决定调用某个工具，Server 执行并返回结果，中间可能穿插 Sampling 或 Resource 读取。

展开看一次真实的用户请求，从提问到拿到答案，中间到底发生了什么：用户提问后，LLM 决定需要调用工具，MCP Client 向 Server 拉取工具清单，LLM 选中目标工具，Client 发起 call_tool 请求，Server 调用后端 API，返回结构化结果，最终 LLM 生成自然语言回答。

注意关键点：LLM 自己并不知道 Docker API 怎么调，它只知道“有一个叫 get_docker_containers 的工具，我可以调用它”。真正的翻译工作，全部发生在 MCP Server 里。

13 三种通信方式，以及协议的演进

目前实际上有三种方式：Stdio 用于本地进程，Agent 和 MCP Server 在同一台机器，官方推荐用于本地工具（如 Claude Desktop 本地插件）；SSE 是早期的远程通信方案，已被标记为历史方案，不推荐新项目使用；Streamable HTTP 是远程部署、多客户端共享的场景，也是官方目前推荐的远程通信标准。

简单判断标准：只在本机跑、给自己用就选 Stdio；要部署成服务、给团队或多个 Agent 共用就选 Streamable HTTP。企业级场景几乎都会走 HTTP，因为 Stdio 依赖进程间管道，没法做鉴权网关、没法做多租户、也没法水平扩展。

把时间线拉长看，MCP 本身也在持续演进：从早期的 Stdio，到 SSE（历史方案），再到当前推荐的 Streamable HTTP，未来还会补齐标准化的鉴权与治理层。传输方式从“本地进程管道”走向“标准 HTTP”，本身就是在为企业级场景铺路。

第三部分：实战（怎么写）

14 一个最简单的 MCP Server：目录结构与职责划分

先讲清楚职责划分：一个 MCP Server 本质只干两件事——告诉 LLM 我有哪些工具（list_tools），LLM 决定调用后真正去执行（call_tool）。

一个规范的目录结构应该长这样：server.py 作为入口，负责 list_tools / call_tool 注册与分发；tools/ 目录按业务领域拆分文件（如 logs.py、docker.py、monitor.py）；api.py 提供统一的 api_call 封装（异步 + 统一返回结构）；config.py 集中管理环境变量、默认值、启动校验。每个文件职责单一，这一点会在第四部分反复用到。

15 Tool 注册：完整的 list_tools 实现

以 Docker 这一个领域为例，一个真实可跑的 Tool 定义长这样：get_docker_containers 用于获取所有 Docker 容器列表及状态，无需输入参数；operate_docker_container 用于操作 Docker 容器（start/stop/restart），需要 source_id、container_id 和 operation 三个参数，其中 operation 用 enum 限定了取值范围；get_container_logs 用于获取 Docker 容器日志，可指定返回行数。

list_tools 返回的是一份“能力清单”，Client 在 initialize 之后会主动拉取这份清单，交给 LLM 决策。可以看到，操作类工具已经用 enum 限定了 operation 的取值范围——这是原始代码里为数不多做对了的地方。

16 Tool 调用：完整的 call_tool 与 api_call 实现

call_tool 是真正干活的地方。一次真实调用 get_docker_containers，api_call 会向 OpenLog 后端发起 GET 请求，后端返回类似这样的 JSON：包含两个容器，openlog-api 正在运行，openlog-worker 已停止。

17 返回结果：LLM 实际看到的样子

call_tool 最终把这段 JSON 原样格式化成字符串后包进 TextContent 返回。也就是说，LLM 拿到的“工具执行结果”，就是一段格式化后的原始 JSON 文本。这里先埋一个伏笔：不同 Tool 返回的字段结构完全不统一，有的返回 {"containers": [...]}，有的返回 {"error": "..."} 或裸数组——第四部分会讲为什么这样不够好。

18 接入 Claude Desktop / OpenClaw / Hermes 调试

写完 Server，跑起来的方式很统一：在对应 Agent 的 MCP 配置里，指定启动命令即可。以 Stdio 方式为例，配置大同小异：指定 command 为 python，args 为 server.py 的路径，env 里配置环境变量。

三端调试的通用排查思路是一致的：先用官方提供的 MCP Inspector 工具确认 Server 能独立跑通，再确认 Agent 端的配置文件路径、环境变量是否正确，最后看 Agent 启动日志里有没有握手成功的记录。跑起来之后，效果是真实可用的：在 Claude Desktop 里问一句“帮我看看 Docker 容器状态”，模型会自动选中 get_docker_containers，把上面那段 JSON 转述成自然语言回答。这也证明了 MCP 的开发门槛并不高——一个下午就能把已有系统封装成 MCP。但“能跑”和“写得规范”是两回事，接下来做一次真实复盘。

特别篇：真正决定 MCP 好不好用的，不是代码，而是 Tool Design

这一章不是写代码，而是设计思想——也是整篇文章里最值钱的一章。它讲的其实已经不是“MCP”本身，而是一套更通用的方法论：如何设计 Tool。这套方法论不局限于 MCP，未来任何形态的 Agent 工具接入，都绕不开这几步。

很多人（包括第一次写 OpenLog MCP 时）踩的坑，本质上都是同一个：一开始就写代码，把已有 API 一比一翻译成 Tool，跳过了设计阶段。真正应该走的七步是：第一步，分析业务能力——先梳理这个系统能对外提供哪些“能力”，而不是急着照抄现有的 API 列表，一个系统里未必所有 API 都值得暴露给 AI；第二步，划分领域——把梳理出的能力按业务领域分组（日志是一类，Docker 是一类，告警是一类），这一步决定了最终会拆出几个 MCP，而不是一个大杂烩；第三步，抽象 Tool——在每个领域内部，按“一个 Tool 只做一件事”的原则拆开，避免出现一个 Tool 里塞了多种操作、靠一个 type 参数分支的情况；第四步，设计 Schema——明确每个参数的类型、是否必填、取值范围，能用 enum 限定的就不要用自由字符串；第五步，编写 Description——把每个 Tool 的描述当 Prompt 来写，说明用途、使用场景、副作用；第六步，统一返回结构——所有 Tool 的返回都走同一套 {success, data, error} 结构，让 LLM 不用每次重新猜字段；第七步，接入业务系统——最后一步才是写 api_call，把前面设计好的 Tool 接到真实的业务 API 上。

第四部分：OpenLog MCP 复盘——第一次写 MCP，我踩过哪些坑？

21 Tool 如何拆分：我把 7 个领域塞进了一个 Server

原始代码里 list_tools() 一口气注册了 14 个工具，覆盖日志、监控、Docker、远程服务器、告警、AI 分析、系统设置——7 个完全不同的业务领域挤在同一个 Server("openlog") 里，违反了“特别篇”第二步“划分领域”的原则。改进方向：至少拆成 openlog-logs（日志分析）和 openlog-infra（Docker/机器/监控）两个 MCP，各自职责单一，权限也能分开管理。

22 Description 怎么写：我写得像注释，不像 Prompt

原始写法只说“操作 Docker 容器：start/stop/restart”，这条描述信息量不够，容易在边界情况下误判要不要调用。更好的写法应该说明输入范围、使用场景和副作用，比如补充“适用于用户明确要求启动、停止或重启某个容器的场景”以及“restart 会导致容器内服务短暂中断，执行前建议先确认容器用途”。一句话记住：Description 要当 Prompt 写，不是当函数注释写。

23 Schema 怎么设计：参数校验形同虚设

原始代码里 source_id 和 container_id 取值没做任何存在性校验，直接拼进 URL 路径。问题有两个：一是取参数直接用方括号，一旦 LLM 传参缺失会直接抛 KeyError，而不是给出可读的错误提示；二是 container_id 这类字段没有做格式校验，理论上存在路径穿越风险。改进方向：Schema 层面能用 enum、pattern 限定的就不要用自由字符串；代码层面取参数统一用 .get()，缺失时返回明确的错误信息而不是让异常直接冒出来。

24 一个 MCP 放多少 Tool：数量没超标，但领域超标了

经验值：一个 MCP 不超过 20 个 Tool。OpenLog MCP 原始版本有 14 个，还没超过这条红线，但因为跨了 7 个领域，实际体验已经打折扣——LLM 在决策阶段要在混杂领域的工具里挑选，选择正确率会下降。数量红线是表象，领域内聚才是本质：宁可多拆几个小 MCP，也不要把无关领域的能力塞进同一个清单。

25 如何返回统一数据：LLM 每次都要重新猜字段

原始写法里不同接口返回的结构完全不统一，成功/失败也没有统一字段。14 个工具对应的 api_call 返回什么结构，完全取决于后端接口本身长什么样，MCP 层没有做任何统一。改进方向：在 call_tool 出口统一包一层 {success, data, error}，让 LLM 每次拿到的结构都是一致的。

26 如何做异常处理：同步阻塞 + 错误信息裸奔

原始代码里异常信息直接原样返回，可能带出内部路径、堆栈等敏感信息，同时 call_tool 是 async 函数，但 api_call 用的是同步阻塞的 urllib，如果同时有多个工具调用在排队，这一个请求会把整个事件循环卡住。改进方向：换成 httpx.AsyncClient 做真正的异步请求，同时对外只返回脱敏后的错误分类，详细堆栈只记本地日志。

27 如何做权限控制：破坏性操作和只读查询走的是同一条路

原始代码里，operate_docker_container 这类破坏性操作和 get_docker_containers 这类只读查询，走的是完全一样的调用路径——只要 LLM 决定调用，就会真的执行，中间没有任何权限分级或二次确认机制。改进方向：区分只读工具和操作型工具，操作型工具建议在 Tool 层面标记风险等级，并要求更高权限的 Token，或者在业务层加一道需要用户显式确认的环节。

28 如何做日志：日志平台自己不打日志

一个有点讽刺的事实：OpenLog MCP 本身是“日志分析平台”的封装，但 Server 自己却没有输出任何运行日志。一旦线上调用失败，只能靠猜测排查。改进方向：至少要记录每次 call_tool 的调用参数（脱敏后）、耗时、成功/失败状态，方便事后排查问题。

29 如何做配置：Token 默认为空且无校验

原始代码里 OPENLOG_TOKEN 默认给空字符串，且没有启动时的校验；limit=100 这样的默认值分散写在多个 call_tool 分支里，属于典型的魔法数字散落问题。改进方向：统一一个 config.py 模块集中管理默认值和校验逻辑，启动时如果关键配置缺失，应该给出明确报错而不是静默运行——尤其是部署到非 localhost 环境时，空 Token 意味着完全没有鉴权，这是一个容易被忽略的安全隐患。

第五部分：企业落地（怎么用）

30 企业为什么需要 MCP

很多 CTO 并不关心 Tool、Description、Schema 这些实现细节，他们只关心一个问题：为什么值得投入资源做这件事？以前，企业每接一个 Agent 场景，都要为每个业务系统单独开发一套接入逻辑。现在，只需要把每个业务系统各自封装一次 MCP，剩下的接入工作就不用再重复。从“N 个系统 × M 个 Agent”的乘法关系，变成了“N 个 MCP + M 个 Agent”的加法关系——这才是企业投入 MCP 的真正价值。

31 如何包装已有 REST API

答案是不需要推倒重来，业务零侵入。OpenLog MCP 本身就是最好的例子——OpenLog 后端是一个独立的 Express 服务，MCP Server 完全不碰后端一行代码，只是在外面加了一层翻译层，把 REST 接口包装成 Tool。MCP Server 是 Adapter，天然就该是新增的适配层，不是对原系统的侵入式改造。

32 SpringBoot 如何接 MCP

企业 Ja va 系统最常见的诉求。核心思路不是改造 SpringBoot 本身，而是新增一个独立的 MCP Server 进程，在 Tool 实现里通过 HTTP Client 回调 SpringBoot 已有的 @RestController 接口。Spring AI 生态已经提供了 MCP Server/Client 相关的 Starter 依赖，可以把已有接口逐个包装成 Tool，不需要脱离 Spring 生态另起炉灶。

33 Go 如何接 MCP

Go 生态有官方及社区维护的 MCP SDK，思路和 SpringBoot 一致：写一个独立的 MCP Server 进程，在 call_tool 里转发调用已有 Go 服务的 HTTP/gRPC 接口。Go 天生的并发模型和轻量协程，反而很适合承载多个 Tool 并发转发调用这种场景，能天然规避前面讲的同步阻塞问题。

34 Python 如何接 MCP

就是本文 OpenLog MCP 的例子，用官方 mcp Python SDK 最省心：list_tools 和 call_tool 两个装饰器即可搭起骨架，配合 stdio_server 或 HTTP 方式对外暴露。Python 生态的 SDK 成熟度目前是几种语言里最高的，适合快速验证和原型开发。

35 一个 MCP 的完整生命周期

企业里一个 MCP Server 从诞生到退役，通常要经历这样一条链路：开发、发布、注册 Registry、Gateway 接入、Agent 发现、调用、日志与监控、升级、废弃。大部分团队只关注“开发”和“调用”这两个环节，中间的“注册”“接入”“监控”“升级”“废弃”往往是空白的——这正是下面几节要补齐的内容。

36 企业如何建设 MCP 平台

企业级场景通常不是一个 MCP，而是一堆 MCP。这里有一个非常常见的坑：很多团队第一反应是写一个“万能 MCP”，把 100 个工具都塞进一个 Server 里。这看起来省事，实际上会造成 LLM 决策正确率下降、权限无法细粒度控制、任何改动都要重新发布整个 Server。正确做法是按领域拆分，上层用 Gateway 统一接入。

37 MCP Gateway

企业级部署中，Gateway 承担统一入口的职责：统一鉴权（不需要每个 MCP Server 各自实现一套认证逻辑）、统一限流与审计日志、按用户/团队做访问控制、把多个 MCP Server 聚合成一份对 Agent 可见的清单。这也是前面“权限控制”在企业场景下的落地方式——单个 MCP Server 内部做不到的细粒度权限，交给 Gateway 层统一收口。

38 MCP Registry

Registry 解决的是“治理”问题：企业内部到底有多少个 MCP Server、分别是谁维护的、当前版本是什么、是否还在被使用。类似企业内部的“API 市场”——团队开发新 Agent 时，先去 Registry 查有没有现成的 MCP 可用，而不是重新造一个轮子。没有 Registry 的企业，往往会在半年后发现团队里悄悄长出了三四个功能重叠的 MCP Server，谁都不知道该用哪个。

39 MCP 权限：OAuth、Token、RBAC、Tool 白名单

企业级场景需要一整套权限体系：OAuth 用于 Agent 代表某个真实用户去调用 MCP，而不是一个共享的静态 Token；Token 用于服务间调用，使用短生命周期的方式；RBAC 实现不同角色能看到、能调用的 Tool 集合差异化，在 Gateway 层统一配置；Tool 白名单用于高风险操作型工具，只在 Gateway 层维护一份被显式授权的 Agent/用户组合才能调用。

40 MCP 可观测性：企业最终都会问的几个指标

MCP 平台跑起来之后，企业几乎必然会问：这些 MCP 到底被用得怎么样？常见的可观测性指标包括：Tool 调用次数（哪些高频、哪些几乎没人用）、成功率/失败率（定位不稳定的 Tool 或后端依赖）、耗时（发现哪些 Tool 拖慢了 Agent 的响应速度）、Token 消耗（Tool 返回内容越冗长、结构越不统一，消耗的 Token 就越多）。这些指标通常也是收口在 Gateway 层统一采集，而不是要求每个 MCP Server 自己实现一套监控上报逻辑。

41 企业最佳实践

汇总一下前面几部分的核心结论：一个领域一个 MCP，不要大杂烩；Description 当 Prompt 写，Schema 做好校验；返回结构统一，异常信息脱敏；破坏性操作要有权限分级和二次确认；MCP Server 要有基本的可观测性；配置集中管理，关键配置缺失时启动即报错；企业级部署统一走 Gateway，谁在维护什么 MCP 交给 Registry 管理。

42 MCP 到底是不是万能的？

看完前面这么多内容，很容易产生一个误解：以后是不是什么都该用 MCP？REST 是不是就没用了？并不是。直接调用 REST 更简单的场景——如果调用方就是一段确定性的程序代码，业务逻辑清晰、不需要“决策”，直接调 REST 接口就够了，包一层 MCP 反而多此一举。Function Calling 就够用的场景——如果这个能力只会被一个特定的 Agent 使用、不需要跨框架复用、也不涉及独立部署和治理，直接在应用内用 Function Calling 定义一个函数即可。值得写 MCP 的场景——这个能力需要被多个 Agent 或多个团队复用，或者需要独立部署、独立鉴权、独立生命周期管理，这时候封装成 MCP 才划算。

43 MCP 未来的发展

最后拔高一下视角。几个值得关注的方向：MCP 会不会真正成为 AI 世界的“USB 标准”，任何工具、任何 Agent 即插即用？会不会出现类似应用商店的 MCP 生态，企业和个人都能发布/订阅 MCP？企业内部系统会不会默认标配一层 MCP，作为对外提供 AI 能力的标准接口？Agent 生态的竞争，会不会从“模型能力”逐渐转向“谁的 MCP 生态更丰富”？

FAQ：读者常问的几个问题

Q：MCP 和 OpenAPI 有什么区别？REST/OpenAPI 面向程序调用，MCP 面向 AI 决策调用。

Q：MCP 和 Function Calling 有什么区别？Function Calling 是模型决定“要不要调用”的能力，MCP 是让工具能被任意模型发现和调用的协议层。

Q：MCP 为什么不用 WebSocket？WebSocket 适合双向长连接，但实现和部署复杂度更高。Streamable HTTP 已经能满足“流式返回 + 请求响应”的场景，同时保持了无状态特性，更方便水平扩展和走标准的 HTTP 网关。

Q：HTTP 和 Stdio 怎么选？本地自用选 Stdio，要给团队或多个 Agent 共用就选 Streamable HTTP。

Q：一个系统应该写几个 MCP？按业务领域拆分，一个领域一个 MCP，不要写“万能 MCP”。

Q：一个 MCP 应该有多少 Tool？经验值不超过 20 个，但数量红线是表象，领域内聚才是本质。

Q：MCP 会取代 REST API 吗？不会。REST 继续服务程序间调用，MCP 是在其之上新增的、面向 AI 的消费层，两者并存。

Q：Skill 和 MCP 有什么关系？Skill 负责“怎么做”（流程编排），MCP 负责“调用什么”（能力封装）。可以理解为：Skill 是剧本，MCP 是演员能做的动作清单。

写在最后

这篇文章按“认知 → 原理 → 实战 → 复盘 → 企业落地”五个阶段展开，中间穿插了一份真实的、第一次写就跑通但不够规范的代码——从完整的 Tool 实现，到设计方法论，再到逐条代码复盘，最后落到企业级的权限、可观测性、Gateway、Registry 方案。

如果你也是刚开始写 MCP，不用追求一上来就写出“教科书级”的代码——先建立认知，按“特别篇”的七步设计，再对照第四部分逐一打磨，最后参考第五部分往企业级去演进，也别忘了回头看看第 42 节，想清楚这次是不是真的需要 MCP。这本身就是大多数人写第一个 MCP 的必经之路。