1. 先搞清楚MCP 到底解决了什么问题2024 年底到 2025 年AI 圈子里几乎每个搞大模型应用的人都在聊 MCP。你要是只刷标题可能会觉得这是又一个新出的模型或者什么神秘的算法框架。但实际上MCP 的全称是 Model Context Protocol翻译过来叫“模型上下文协议”它不是一个具体的模型而是一套给 AI 接外部世界的通用接口规范。说人话就是以前你想让 AI 帮你查天气、查数据库、操作 Figma、读文件、干活你得给每个 AI 应用单独写一套对接代码。A 应用一套B 应用一套C 应用再来一套而且这些代码几乎没法复用。今天你用 LangChain 写了一个查数据库的工具明天换到另一个框架基本等于推倒重来。MCP 想干的事情就是把“AI 和外部工具之间怎么对话”这件事标准化像 USB 接口一样——你做了一台支持 USB 的电脑那你做的 U 盘、鼠标、键盘插上去就能用不用每家都单独设计一个专用插口。那这套“USB 接口”到底是谁来定义的是 Anthropic 在 2024 年 11 月开源的一个协议规范后来在 2025 年 3 月捐赠给了 Linux 基金会现在由 Linux 基金会的联合开发基金会来管理。这步很关键——它意味着 MCP 不再是某一家公司的私有接口而是行业共同维护的开放标准。就像 HTTP 不是某家公司的私有协议一样MCP 想要成为 AI 应用与外部工具之间的事实标准。MCP 的价值定位非常清晰大模型本身住在服务器里它不知道你电脑里有什么文件不知道你数据库里有什么表不知道你今天要操作什么工具。MCP 就是给模型装上“手和眼睛”的那层桥梁。你可以把它拆成三个角色去看MCP Host宿主、MCP Client客户机、MCP Server服务器。宿主是 AI 应用本身比如 Claude Desktop、Cursor、Codex 这类工具Client 是宿主内部负责跟外部通信的组件Server 则是你提供具体能力的服务端程序比如一个“查询天气”的服务、一个“读写数据库”的服务。这套架构的好处在于每个 MCP Server 都是独立部署、独立维护的。你想让 AI 新增一个能力不需要改 AI 应用本身的代码只需要起一个新的 MCP Server然后在宿主里配置一行地址就完事了。这种“插拔式”的设计直接改变了 AI 应用开发的底层工作方式。2. MCP 的核心架构拆解Client、Server 与协议模型2.1 三个角色各管什么我先用一个来类比假设 AI Agent 是一个大公司的老板他不可能自己下场干活他需要联系供应商。MCP Host 就是老板本人AI 应用MCP Client 是老板的秘书负责拨打电话、传达指令MCP Server 则是各个供应商——有快递公司文件读写、有调查公司搜索查询、有财务公司数据库操作。技术上的分工大概是这样的MCP HostAI 应用本体负责调用大模型、处理用户输入、展示结果。它要理解 MCP 的能力列表然后在合适的时候把请求转给合适的 Server。MCP ClientHost 内部实现的一个协议客户端负责与 Server 建立连接、发送请求、接收响应。一个 Host 可以同时连接多个 Client 实例每个 Client 对应一个 Server。MCP Server一个轻量级的服务程序暴露出一系列“工具Tools”“资源Resources”“提示词Prompts”底层可以对接任何外部系统——文件系统、数据库、HTTP API、搜索引擎、设计工具等。连接方式上MCP Server 有两种形态一种是本地通过**标准输入输出stdio**与客户端通信适合在用户自己电脑上运行的场景另一种是通过HTTP Server-Sent EventsSSE进行远程通信适合部署在服务器上供多个客户端或远端 Agent 调用。传输方式这块值得多说一句。本地场景用 stdio本质上就是启动一个子进程进程之间通过 stdin/stdout 来传 JSON 消息。这种方式的好处是稳、快、不走网络没有端口冲突问题。而远程场景走 HTTPMCP 协议把每个 Server 能力暴露成 URL 端点然后用 JSON-RPC 2.0 格式来封装请求和响应。2025 年年中又推出了 Streamable HTTP 传输规范逐渐取代早期以 SSE 为主的远程实现让长连接和流式响应处理得更干净。2.2 MCP 协议的数据模型不只“工具”这一种能力很多人一提到 MCP 就以为它只是“让 AI 能调用函数”这个理解太窄了。MCP 的抽象对象一共分为三类Tools工具、Resources资源、Prompts提示词模板。Tools 是“动词”是 AI 可以执行的操作。比如查询天气、提交订单、创建文件、发送邮件。Tools 通常需要入参有明确的返回值。AI 在对话过程中会根据你的问题自动判断该调用哪个 Tool并填充参数。Resources 是“名词”是可供 AI 读取的上下文数据。比如一个文件的内容、一张数据表的记录、一个项目的说明文档。Resource 不强调“能不能做”而强调“有没有、能不能读”。Host 启动时可以自动把某些 Resource 加载进上下文让模型“天生就知道”某些领域信息。Prompts 则是预定义的提示词模板。它们的目的是把常用的任务流程固定下来。比如你定义了一个“周报生成 Prompt”里面写好了角色设定、输出格式、必须包含的模块用户在宿主里一键调起AI 就按这个模板去执行省得每次重复打同样的话。这三类对象加在一起才构成了完整的“上下文接入”能力。工具让 AI 能动作资源让 AI 有信息提示词让 AI 有套路。你去看一个成熟的 MCP Server往往不是只提供两三个 Tools 就算了而是会同时暴露一组资源文件和一组提示词模板这样接入方的使用体验才会完整。2.3 从握手到调用一次完整的 MCP 交互流程MCP 的底层消息格式走的是 JSON-RPC 2.0这是一套很经典的远程调用协议。JSON-RPC 2.0 的好处是它很轻、无状态、人类可读。MCP 在 JSON-RPC 之上定义了自己的方法名和参数语义主要包括下面几个环节第一步是初始化握手。Client 发送initialize请求带上自己支持的协议版本号、客户端标识、能力声明Server 返回自己的协议版本、服务端能力、以及补充信息。这一步的作用是让两边对齐“都能听懂什么话”规避版本不兼容的问题。第二步是能力协商与枚举。初始化之后Client 会调用tools/list、resources/list、prompts/list来获取 Server 暴露出来的能力清单。这个清单不是写在配置文件里写死的而是通过协议动态获取的——这样 Host 就知道接下来可以调用哪些工具。有些 Host 还会同时读取每个 Tool 的输入 JSON Schema用来约束大模型生成参数时的格式。第三步是调用。当 AI 判断“此刻需要调用某个工具”Client 发tools/call请求带上工具名和参数。Server 执行具体的业务逻辑可能是查表、调第三方 API、操作本地文件然后把结果返回。结果通常包括内容片段文本、图片和可选的isError标记。如果执行过程中出了错Server 要返回结构化错误信息供模型判断下一步怎么处理。第四步是通知与采样。MCP 还支持日志通知、进度通知、资源更新通知等。其中比较有意思的是“采样”机制——它允许 Server 反过来请求 Host 调用大模型来生成内容。这招在“需要 Agent 帮忙总结文件”的场景里特别有用Server 发现自己手里的数据太散没法直接给结果就会返回一个“我去请大模型帮我提炼一下”的请求。整个流程走下来你就会发现 MCP 本质上并不是什么高深莫测的新技术它更像是一个为了 AI 应用场景重新组织的接口协议。它没有发明新的传输层没有发明新的序列化格式而是站在 JSON-RPC 和 HTTP 的肩膀上把“AI 怎么发现能力、怎么调用能力、怎么理解结果”这件事系统地定义了一遍。3. 手把手搭建一个 MCP Server从零到被 AI 调用讲完协议层面的东西最关键的问题是代码到底怎么写我自己的学习路径是从一个极简的天气查询服务入手的这个例子足够小能覆盖一个 MCP Server 的核心要素又不会让你陷入业务复杂度里出不来。下面给出完整的实操过程建议你边看边敲。3.1 环境准备与 Python SDK 选型我用的是 Python 生态MCP 官方 Python SDK 已经比较成熟直接从 PyPI 安装即可pip install mcpSDK 本身依赖比较少装好之后会有自带的一个命令行工具方便联调。如果你用的是 Node.js 生态官方也有对应的 TypeScript SDK语法上大同小异。一般基础项目用 Python 就够了。接下来我想搭一个“查询城市天气”的 MCP Server。这个服务内部其实是通过访问一个第三方的天气 HTTP API 拿数据再把数据封装成 MCP 工具暴露出去。也就是说MCP Server 不自己产生数据它做的本质是“协议翻译”——把外面杂七杂八的 HTTP 接口翻译成 AI 能理解、能调用的标准化工具。3.2 核心代码实现FastMCP 极简编写风格MCP Python SDK 里提供了一个叫FastMCP的高层封装类可以极大简化服务端开发。你不需要手写 JSON-RPC 的消息解析只要注册几个函数SDK 自动帮你把函数变成了 MCP Tools。from mcp.server.fastmcp import FastMCP import httpx import json mcp FastMCP(weather-server) mcp.tool() def get_weather(city: str, days: int 1) - str: 获取指定城市的天气预报。 Args: city: 城市名称例如 北京、上海、广州。 days: 获取未来几天的预报默认 1 天。 # 这里以调用一个模拟的天气服务为例 # 实际项目里可以把 URL 换成任意第三方 HTTP API url fhttps://api.example.com/weather?city{city}days{days} resp httpx.get(url, timeout10) data resp.json() return json.dumps(data, ensure_asciiFalse) if __name__ __main__: mcp.run(transportstdio)这段代码可以说是 MCP Server 的“最小可运行版本”——只用了三个关键要素mcp FastMCP(weather-server)声明一个 Server 实例名字会显示在客户端的工具列表里。mcp.tool()装饰器把下面的普通函数暴露成一个 MCP Tool。函数的 docstring 会被自动解析成工具描述参数类型和默认值也会被自动解析成 JSON Schema。所以你在写函数时docstring 一定要认真写因为模型理解这个工具能不能满足当前任务靠的主要就是这段描述。mcp.run(transportstdio)以标准输入输出方式启动服务供本地客户端连接。有的读者会问这里为什么要用 stdio 而不是 HTTP原因是用 Claude Desktop 这类本地桌面宿主连接 MCP Server 时默认就是 spawn 一个子进程通过 stdio 来通信。stdio 模式没有端口、没有鉴权问题最省事。等你把 Server 调试通了再部署到服务器上改用 HTTP 模式也不难。3.3 服务端暴露多个工具与资源扩展你的 Server上面那个 Server 只做了一个工具真实项目往往需要多个工具配合。你可以直接在同一个类里叠加注册工具之间共享内部状态。假如我想再加一个“根据天气推荐穿衣”的功能代码很简单mcp.tool() def recommend_clothing(weather: str, temperature: float) - str: 根据天气和温度推荐穿衣建议。 Args: weather: 天气描述如 晴、雨、雪、阴。 temperature: 当前温度摄氏度。 if 雨 in weather or 雪 in weather: return 有降水建议带伞穿防水外套 if temperature 5: return 寒冷建议穿羽绒服、戴围巾手套 if temperature 15: return 较凉建议穿风衣或夹克 return 温暖建议穿衬衫或薄外套注意MCP 工具跟普通 Python 函数最大的区别在于它是给大模型“看得到”的。模型不会像人一样自己找函数说明它完全依赖工具名、docstring、参数 Schema 来判断工具用途。你如果写一个名字含糊不清、描述也不明朗的工具模型很可能永远不调用或者乱调。这件事我之前踩过不少坑。另外如果你想让 AI 能“读取”某些项目上下文比如一个 README 内容、一个数据库的连接信息模板可以暴露 Resourcesfrom mcp.server.fastmcp import FastMCP mcp FastMCP(doc-server) mcp.resource(docs://project-readme) def get_readme() - str: 获取项目说明文档内容。 with open(./README.md, r, encodingutf-8) as f: return f.read()定义好 Resource 之后当客户端连接到这个 Server宿主可以主动获取这份文档放进模型上下文。这个机制在做“项目级 AI 助手”时特别好用比如你把项目规范、代码结构说明作为 Resource 挂上模型一开始就了解了整个项目背景回答质量会明显提升。3.4 本地联调用官方调试工具验证你的 Server写完了 Server你不能直接说它就能用得先联调。MCP SDK 内置了一个命令行调试工具你可以把 Server 跑起来试试消息交互npx modelcontextprotocol/inspector python weather_server.pyInspector 工具会打开一个本地 Web UI你能在里面手动连接你的 Server浏览 Tools 列表填参试调查看返回。这个工具特别适合开发期的快速验证——它能让你脱离 AI 宿主环境直接测试 Server 本身是否工作正常。我在日常开发中习惯先把 Server 的每个工具都在 Inspector 里跑一遍确认无误再接宿主能省去很多“到底是工具问题还是模型调度问题”的排障时间。如果你的 Server 已经被宿主连接还可以直接看宿主日志。Claude Desktop 这类宿主有时会把 MCP 通信细节打印到日志里方便你排查工具注册、参数传递等环节的问题。接宿主时配置方式是写一个 JSON 配置文件。以 Claude Desktop 为例常见配置放在macOS:~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:%APPDATA%\Claude\claude_desktop_config.json配置内容大致如下{ mcpServers: { weather-server: { command: python, args: [/absolute/path/to/weather_server.py] } } }配好之后重启宿主编译就能在客户端设置里看到新接入的 Server。注意路径建议写绝对路径Python 建议用虚拟环境里的绝对路径。我之前有几次接入失败最后发现就是python命令指向了系统 Python而依赖装在虚拟环境里导致子进程启动时找不到包直接崩溃。3.5 用 Java 技术栈实现 MCP Server 的路径参考如果你主要用 Java 后端其实也有成熟的支持方式。2025 年之后Spring AI 官方加入了 MCP 客户端和服务端支持底层走的是io.modelcontextprotocol.sdk:mcp这个 Java SDK。你可以在服务端定义一个工具类比如模拟一个查订单的接口然后用ToolCallback暴露给 MCP 客户端。Solon AI 框架也对接了 MCP启动时自动扫描并注册工具。Java 技术栈做 MCP Server 的好处在于企业后端服务大都是 Java 写的MCP Server 可以直接嵌在现有 Spring Boot 应用里把那些已经存在的业务接口包装成 MCP 工具不需要引入一套新的服务框架。Spring AI 这边大致配置是引入spring-ai-starter-model和 MCP Server Boot Starter在配置里声明 Server 的 name 和 version然后写一个普通的Component里面定义带Tool注解的方法。项目启动后自动注册宿主通过http://localhost:8080/mcp就能远程连接。这套方式对企业级落地非常友好不过配置项比 Python 版多一点需要先熟悉 Bean 的装配方式。4. 围绕 MCP 的工具链生态不只是“又一个接口规范”4.1 热门 MCP Server 盘点蓝湖、Figma 与浏览器自动化MCP 能火和它迅速长出来的生态有直接关系。光有协议没有工具这个东西就是空壳。好在这两年各领域的客户端产品都在积极做“MCP Server”作为自己能力的输出口。把热搜词里出现频率比较高的几个梳理一下Figma MCP / 蓝湖 MCP。设计工具接入 MCP 之后最大的价值场景是“设计稿一秒变前端代码”。以前设计师出 Figma 稿前端工程师照着稿子手写 HTML/CSS。现在你让 AI 编程助手通过 MCP 连上 Figma它可以直接读取设计稿的图层树、样式属性、组件信息然后生成还原度极高的代码。蓝湖Lanhu做的 MCP 也一样就是把设计稿的元素提取能力开放给 AI Agent。这个赛道本质上是“设计工程化”的又一次延伸——从切图工具到自动生成代码再到 AI 直接理解设计意图链路越来越短。Playwright MCP。这是浏览器自动化领域的杀器。Playwright MCP Server 把浏览器操作封装成工具集合比如browser_navigate打开页面、browser_click点击元素、browser_type输入文本、browser_snapshot获取页面可访问性快照。AI Agent 接入之后能自己打开网页、自己操作按钮、自己填写表单、自己验证结果。这不就是我们一直想要的那口“AI 帮你测网站”吗很多做 E2E 测试的团队已经把它用在智能回归测试和自动化 bug 复现里了。Unity MCP / Cocos Creator MCP。游戏开发场景也在拥抱 MCP。Unity MCP 允许 AI 助手读取场景结构、查找游戏对象、修改组件属性、执行 C# 脚本Cocos Creator 也有类似的 MCP 桥接方案。你用自然语言给 AI 下指令说“把主场景的主角移动速度调低 20%”如果有 MCP 连着引擎AI 真的能直接改场景里的数值。这块目前还在早期但它代表了一个趋势只要引擎愿意提供操作接口AI 就能变成“能干活的生产力工具”而不只是“写代码的建议器”。Mobile MCP / 移动端设备控制。在移动端自动化上MCP 也开始渗透比如把 Android 的 adb 命令封装成 MCP ServerAI 就能自动操作模拟器甚至真机安装 App、点击坐标、抓取截图。移动端 UI 测试自动化和 AI 兜底复测可以串起来了。我建议新手选第一个自己接的 MCP Server 时优先挑 Playwright MCP 或一个官方示例 Server因为它们生态完整、文档多、踩坑概率低。如果你想看业务价值就挑一个跟你日常工作强相关的比如做前端的选 Figma MCP 或蓝湖 MCP做后端的选数据库 MCP 或 HTTP 请求封装直接把你手头最繁重的“信息搬运型”工作交出去你会立刻体会到 MCP 的爽感。4.2 Computer Use 与 MCP 有什么不同很多文章会把“Computer Use”和 MCP 放在一起比较还有人把概念搞混。这里我解释清楚。Computer Use 指的是让 AI 像人一样操作电脑——看屏幕、移动鼠标、点击、敲键盘。它模仿的是“人类操作介面”的方式也就是图形界面交互。如果 AI 要帮你写一封邮件它不是调用 Mail API而是像你一样打开邮件客户端、找到写信按钮、逐字敲进去。这种方式不需要对方系统定制接口什么软件都能操作但慢、不稳、需要视觉理解模型的参与。MCP 不一样它走的是结构化接口契约。AI 操作的不是像素而是对方系统预先定义好的工具——比如“send_email(receiver, subject, body)”。它的前提是系统方必须开发一个 MCP Server 把能力暴露出来但一旦暴露出来调用极其稳定、速度快、返回结构化数据。这两种方式的优劣很清楚维度Computer UseMCP交互对象屏幕图像图形界面结构化接口工具函数系统适配成本无需定制任何可看的界面都能操作需要系统方提供 MCP Server稳定性低受界面变化、视觉识别影响高接口不变则稳定速度较慢像人看屏幕一步步操作较快直接走协议执行适用场景老系统、无 API、无法改造的外部产品自有系统、有开发能力的平台真实生产中二者不是二选一而是互补的。MCP 能覆盖的优先用 MCPMCP 覆盖不到的比如一个第三方老系统没有任何接口再用 Computer Use 兜底。理论上未来的 Agent 既会调 MCP 也会操作电脑“能上路的车走高速上不了路的走省道”。4.3 普通 REST API 与 MCP 的取舍什么时候值得上热搜词里“接口”一词反复出现比如“接口是啥”“API 接口”“后端提供接口”“list 接口”“接口幂等性”“接口自动化”等这些东西和 MCP 什么关系这里我想专门掰扯一下。普通 API 是“给程序用的接口”MCP 是“给 AI 用的接口”——这是最本质的差异。后端团队提供一个 REST/orders?userId123接口是给前端页面调用的页面代码写死了“点击按钮就请求这个 URL”。但当你面对 AI 时它的输入是自然语言它不知道你的 API 文档不确定要传什么参数也不清楚哪些接口能组合完成一个复杂任务。所以直接让 AI 去调你的 REST API往往会失败。MCP 的价值在于给 API 加了一层“AI 友好的描述层”。你的 MCP Server 里可以写清楚“这个接口是查订单的用户 ID 是必填项订单状态可选”“那个接口是发货的”然后暴露成工具。AI 拿到这些描述之后就能自己规划任务流程先查订单再调发货。但这不意味着什么接口都要包一层 MCP。我的建议是无状态、简单的“查询类”单接口没必要包 MCP——直接让 AI 框架调用普通 HTTP 工具就行。涉及多步骤流程、需要决策分支、需要容错重试的“任务类”能力才值得包成 MCP。如果某个工具会被多个不同 AI 应用复用比如多个 Agent 都要查你们公司的客户信息就非常值得做 MCP Server因为它一次对接处处复用。判断标准其实可以就一条“能力的消费方是固定前端的还是不确定的智能体”如果是后者用 MCP 的思路去暴露能力能省很多将来往返协调的功夫。5. 实战中会踩的坑注册失败、鉴权紊乱和工具调不动5.1 Figma MCP 在 Codex 里工具注册不上怎么排查热搜词里那条“Figma MCP 在 Codex 中总是工具注册不上”的词条我猜是从某个真实求助问答里来的。这个问题的本质不是 MCP 协议本身的问题而是 MCP Server 从启动到工具列表交付中间某个环节断了。我自己排查的思路固定在三个层面第一层Server 是否启动成功。很多人配置了 MCP Server 地址但它启动后报错退出。Figma MCP 要走 OAuth 令牌认证如果你首次启动时没有正确粘贴访问令牌Server 进程起来之后监听到错误会直接卡住或者返回一个空列表。排查办法在 Codex 的 MCP 配置里找到 Server 的启动命令手动在终端里跑一遍看有无报错。第二层工具列表是否返回。MCP 客户端注册工具靠的是tools/list这个请求。如果 Server 返回的是空数组客户端界面自然什么都不显示。Figma MCP 返回空列表常见的原因有两个配置文件里没填 API Token或者 Token 对应的 Figma 账号没有访问目标文件的权限。这个可以通过用 curl 去调用 Figma API 测试看那个 Token 能不能取到文件数据验证权限链路。第三层宿主软件配置与版本问题。Codex 这类 CLI 工具对 MCP 的配置文件格式要求可能不同有些版本只支持本地 stdio Server有些版本支持远程 HTTP Server。如果你把 HTTP URL 填到了不支持它的版本里当然注册不上。这时候要么升级宿主要么把 Figma MCP 换成本地启动的方式。这种排查逻辑不只适用于 Figma MCP——只要你在任何宿主里遇到“工具注册不上”都建议按照这个三步走看服务有没有起来、看服务有没有返回能力、看宿主有没有正确读取配置。5.2 本地 stdio 服务启动失败和处理办法stdio 模式的 MCP Server 是宿主作为父进程 spawn 出来的子进程。宿主跟你平常在终端里手动运行程序不同它的 PATH 环境、当前工作目录都由宿主进程决定。所以常见的两个坑是command写了python但系统里同时存在多个 Python选中的那个没有装 MCP SDK子进程起来后立刻报ModuleNotFoundError。Server 脚本里用了相对路径去读文件但宿主启动子进程时的工作目录并不是你的项目目录导致文件找不到。解决办法非常朴素command 写成虚拟环境中 Python 的绝对路径比如/Users/me/.venv/bin/python脚本内部涉及文件路径时一律基于__file__算绝对路径。这个坑我在写自己的首个 MCP Server 时踩过现象特别诡异——手动跑一切正常一接宿主就报错后来在日志里才发现是工作目录的问题。排查这类问题还有一个实用的工具——重定向 stdio 日志。MCP 通信走的是 stdin/stdout你千万不能在 Server 里乱写print否则会污染协议消息。如果你非要打日志把日志写到 stderr 或者独立日志文件里否则客户端解析 JSON-RPC 时会直接报错。5.3 鉴权与安全API 密钥、令牌不能出现在工具描述里MCP Server 的本质是一个提供执行能力的服务所以安全问题必须重点对待。最常见的反面教材是有人把数据库连接串或者 API Token 硬编码进 MCP Server 代码里然后配套的 Python 脚本随意分发给别人。一旦这个 Server 被其他人启动等于他把你的数据库钥匙也一并拿走了。建议做好这几件事敏感凭据放在环境变量里读取不要提交到代码仓库。MCP Server 应明确给每个工具标注权限级别。比如“只读型工具”查询数据和“写操作型工具”删除数据、提交订单在描述中就要区分清楚。AI 一旦能理解这些注解就不会乱调用写操作。远程 MCP Server 一定要做鉴权不能裸奔在公网。目前官方推荐在 HTTP 层引入 Bearer Token 或 OAuth。如果还没有统一的 MCP 鉴权规范至少在网关层加一道访问控制肯定没坏处。从长期看MCP 在安全方面还会演化出更细的授权模型。但现阶段工具健壮性掌握在开发者手里。你自己写 Server 时要把每个工具都当成“可能被任何恶意调用的人触发”来对待输入校验、越权判断、频率限制这些后端基本功一个都不能少。5.4 工具被 AI 频繁调用出错幂等性与上下文被撑爆热搜词里提到了“接口幂等性”这个词在做 MCP Server 时也重要。AI Agent 调工具并不总是按人的预期来的它可能失败后重试也可能因为网络波动重复发请求。如果你的 MCP Server 里有一个“创建订单”的工具它被执行了两次用户就收到了两笔扣款——这就灾难了。所以写 MCP Server 时凡是“会产生副作用”的工具尽量做成了幂等设计提供一个幂等键服务端内存或数据库里保存处理记录重复请求直接返回第一次的结果。还有一个问题很隐蔽上下文被撑爆。MCP 工具的返回结果会被原样塞给大模型如果某个工具返回了一个几兆字节的大数据比如查询了整张表你的上下文长度马上被占光后续对话质量骤降。更好的做法是返回数据前先做截断或聚合最多返回前几十条记录再额外提供“加载更多”这类翻页工具。好用的 MCP Server第一个素质就是“懂取舍”——不是把什么都一股脑给模型而是给模型恰到好处的信息量。