企业官网建设流程全解析

最近社区里关于 MCP 的讨论，几乎已经到了逢 AI 必提的程度。Figma MCP、MySQL MCP、Playwright MCP、x64dbg MCP 一堆项目接连冒出来，群里天天有人问“Cursor 怎么配 MySQL 的 MCP”“Codex 里面怎么添加 MCP”“为什么 Figma MCP 在 Codex 中工具注册不上”。

但聊得越多，我越发现一个现象：大部分人把 MCP 理解为“一种让 AI 调用外部工具的新格式”，仿佛它就是个升级版的 function calling。如果你也这么想，那大概率会遇到一个奇怪的问题——按教程配好了 MCP Server，模型却不调用、工具列表注册不上、或者调用一次就报错。这时候再回去看官方文档，又会陷入另一个极端：一堆 schema、协议、原语，看完更懵。

这篇文章我想换个角度，用第一性原理把 MCP 重新拆一遍：它不是工具调用的格式升级，而是一套“能力协议”。搞清楚这件事，你再看那些工具注册不上、描述不生效、上下文不同步的问题，基本能自己推断出原因，而不是满世界搜教程。内容适用于正在用 Cursor、Codex、Cline 的开发者，也适用于准备自己写 MCP Server 的人。

1. 工具调用的旧范式，到底卡在哪

1.1 旧时代的工具调用是什么样

在大模型真正能“调用工具”之前，大家做 AI 应用基本是这么个套路：你写一个函数，比如get_weather(city)，然后在 prompt 里把函数名、参数、用法告诉模型，等模型输出一段结构化的 JSON，你再去执行这个函数，把结果拼回 prompt。OpenAI 把这件事产品化之后，它叫 function calling。

这招确实有效，模型不再是只能聊天的玩具，它能查数据库、能发请求、能操作外部系统。很多早期的 AI Agent 产品，本质就是一堆函数围绕一个大模型转。每个函数接口写得清清楚楚：入参是什么类型、哪个必填哪个可选、返回什么结构。模型只要按照 JSON Schema 老老实实填参数就行。

我自己早期做项目也这么干过，给一个内部运营机器人挂了十几个函数，有查订单的、有改状态的、有发消息的。一开始效果还行，因为这十几个函数都是我们自己定义、自己调用，模型和函数之间是“主子关系”——模型出参，系统执行。

但问题也出在这个“主子关系”上。

1.2 当工具数量膨胀后，问题全暴露

当你只需要十几个函数、而且都由自己的代码调用时，function calling 够用了。但当工具数量膨胀到几十上百个，甚至这些工具来自不同的第三方系统时，问题就全冒出来了。

第一个问题是工具列表的扁平化。每次请求，模型都要在一大串工具定义里挑该用哪个。工具越多，模型的选择就越不稳定。你写了一个send_email，又写了一个send_email_with_template，再写一个batch_send_email，模型大概率会懵：三个看起来差不多，到底选哪个？描述写得不清晰的话，它会选错。

第二个问题是工具的标准完全不统一。A 系统返回的错误码是40001，B 系统返回的是"INVALID_PARAM"，C 系统干脆抛异常。你的代码为了兼容这些工具，要写一堆胶水逻辑、适配层、转换器。每接入一个新工具，就要给模型写一份新“说明书”。

第三个问题，也是我最想强调的：这种模式下，模型根本不理解工具背后的能力边界，它只是在玩“参数填空”。你给它一个git_commit(repo, message)，它知道要填仓库名和提交信息，但它不知道这个仓库是不是允许 commit、不知道自己有没有权限、不知道这个操作会不会触发 CI。这些信息散落在文档里、代码里、人的脑子里，唯独不在“工具调用”这个环节里。

1.3 “工具列表”不是能力，只是目录

拿生活打个比方。老式工具调用像什么？像你在一个巨型仓库里工作，仓库管理员每隔五分钟给你递一份新的工具清单，清单上写着“钳子：夹紧用，参数 X”“扳手：旋转用，参数 Y”。你要用哪个，得自己猜，还得祈祷每种工具真能干活。

但真正专业的协作不是这样的。你去一个装修队干活，你不需要知道工头仓库里每一把钳子的品牌和型号，你只需要告诉工头“我要固定这块木板”，他会评估自己有没有电钻、有没有合适的螺丝、自己有没有这个权限，然后给你一个确定的答复。

这个差别，就是“罗列工具”和“声明能力”的差别。MCP 真正革新的地方，就是把前者变成后者。

2. MCP 的第一性：能力协议的五层设计

2.1 协议不是格式，是协商规则

很多人一看 MCP 的文档就头晕，因为里面全是initialize、tools/list、tools/call、prompts/get这类词。说实话，我第一次看的时候也没坚持十分钟，心想这不就是 JSON-RPC 换了个皮吗。

后来我在自己写 Server 的时候才慢慢意识到，MCP 真正高明的地方不在于那几个方法名，而在于它定义了一整套“模型与工具之间的协商规则”。这就像 HTTP 协议，它的核心不是 GET/POST 那四个字母，而是定义了客户端和服务端怎么建立连接、怎么请求、怎么响应、怎么处理错误。

这套协商规则可以拆成五层来看。你在用任何 MCP Server 的时候，其实都在走这五层，只是你没意识到。

2.2 能力发现：让智能体知道“你有什么”

MCP 的第一个核心机制，我称之为“能力发现”。客户端（比如 Cursor、Codex、Cline）连上你的 MCP Server 之后，第一件事不是去调用工具，而是先问一句：你有哪些能力？

对应到协议上，就是tools/list。你的 Server 返回一个工具清单，但每个工具不仅仅是“函数名 + 参数”，而是一个带完整语义描述的“能力点”。比如你暴露一个create_jira_ticket，协议层面它是个工具，但语义层面它声明的是“我可以帮你在 Jira 里创建工单”。

正是这一步把 MCP 和普通 function calling 区分开了。function calling 下，模型的“工具列表”是写死在系统 prompt 里的；MCP 下，模型是动态向 Server 查询的。这意味着你不需要改模型，只需要在 Server 里加一个工具，模型下次握手时就会发现它。我做 Codex 接入实验时感受特别明显，新增一个函数后完全不用改任何 prompt，重启会话就自动识别了。

2.3 能力描述与入参契约：从“按格式传参”到“按语义调用”

能力发现之后，模型要真正使用这个工具，还得理解每个能力的使用条件。这就是第二层：能力描述与入参契约。

JSON Schema 在这里承担了重要角色。但 MCP 对 Schema 的要求比 function calling 更严格——它不只是校验字段类型，还承担“语义契约”的功能。什么意思？一个工具的参数如果只写了type: string，模型就知道“这需要传个字符串”，但不知道传什么、往哪传。

我自己写 Server 的时候，踩过最大的坑就在这。我最初给一个代码分析工具写的参数描述是filePath: string，模型确实会传字符串，但经常传一个相对路径，而工具端需要的是绝对路径，结果每次调用都报文件不存在。后来我在描述里明确写上“必须是仓库根目录下的绝对路径，示例：/home/user/project/src/main.py”，错误率才降下来。

这就是语义契约的作用：你在告诉模型的不只是“这个参数是字符串”，而是“你应该传一个满足什么语义的字符串”。MCP 并不限制你怎么描述，但协议的设计鼓励你这样做——把每个参数当成一个需要模型去理解的概念，而不是一个等待填充的格子。

2.4 能力执行与安全边界

第三层是执行与安全。MCP 的tools/call方法负责实际执行，但协议在这里留了很多安全设计空间。

比如，MCP 支持 Server 端在响应里返回isError字段。这个字段很小，但意义重大：它表示“调用本身收到了，但业务执行失败”。我见过不少团队忽略这个字段，把所有非 200 状态都当成协议错误去处理，结果模型收到一堆乱码异常，根本没法做下一步决策。正确做法是：系统错误（协议层失败）直接抛异常，业务失败（比如“订单已关闭”“仓库不存在”）要放在正常响应里，置isError: true。

另一个安全设计是采样与权限提示。MCP 协议允许 Server 在需要用户确认时，通过“请求用户输入”的方式打断流程。说白了就是：工具可以执行，但涉及敏感操作前先问人。很多团队把这一层直接用代码写死（比如只在指定的服务器 IP 上运行），但协议层面其实给了你更优雅的交互实现方式。

2.5 能力组合、上下文同步与协议演进

最后两层，是能力组合与上下文同步。MCP 的原语不止 tools，还包括 Resources（资源）和 Prompts（提示词）。Resources 更像是给模型提供背景材料，比如一个项目的配置文件、一份设计文档；Prompts 是预先写好的模板，用来触发某些固定流程。

这三者合在一起，才构成完整的“能力协议”。工具支持“做一件事”，资源支持“理解一件事”，提示词支持“发起一件任务”。你的 MCP Server 如果只实现了工具，那它只是个“远程函数库”；如果你同时定义了资源和提示词，它才更接近一个“能力完整的小助手”。

而上下文同步这个点，很多时候被大家忽略了。MCP 支持在客户端和服务端之间同步上下文，比如模型操作了某个文件、修改了某个状态，Server 可以感知到。这意味着多个工具之间不是孤立的，它们可以围绕同一个“任务上下文”协作。我做过一个代码审查 MCP，工具 A 负责扫描文件，工具 B 负责分析依赖，它们共享同一个“当前仓库状态”的上下文，配合就很顺。

3. 实操：把心态从“写工具”切换成“设计能力协议”

3.1 动手前先想清楚：你暴露的是函数，还是能力

理论讲再多，不落地都是空的。这部分我直接拿一个实战案例来演示。

假设我们要做一个“项目工时统计 MCP Server”，它要能对接某个内部任务系统，帮使用者统计某个成员在某个时间段内投入了多少工时。如果按旧思路，我会直接写一个函数：

def get_work_hours(member_id, start_date, end_date): pass

然后把它注册成工具，完事。

但如果按“能力协议”的思路去想，我会先问几个问题：模型知道member_id从哪来吗？它知道“工时”在这套系统里的计算口径吗？它如果需要先查成员列表、再查工时，这个流程怎么衔接？

这几个问题想清楚之后，我要暴露的就不再是一个孤零零的get_work_hours函数了，而是一组相互关联的能力：查成员列表、查项目列表、按条件统计工时、判断统计口径。每一个能力都是模型完成“统计工时”这个任务的一个环节。

这个思考过程，就是从“写工具”到“设计能力协议”的切换。工具是你有什么函数；能力是模型能用你做什么事。

3.2 用 FastMCP 搭建 Server：核心代码逐段拆解

我用 Python 的fastmcp库来演示，因为它把底层协议细节封得很好，非常适合展示“能力协议”的建模思路。

先装依赖：

pip install fastmcp

然后定义一个最基础的能力——获取支持的项目列表：

from fastmcp import FastMCP mcp = FastMCP("工时统计服务") @mcp.tool() def list_projects() -> list[dict]: """获取当前系统支持统计的所有项目列表。 返回示例： [ {"project_id": "P001", "name": "官网重构", "owner": "张三"}, {"project_id": "P002", "name": "App 3.0", "owner": "李四"} ] """ # 实际实现可以查询数据库或调用内部 API return [ {"project_id": "P001", "name": "官网重构", "owner": "张三"}, {"project_id": "P002", "name": "App 3.0", "owner": "李四"}, ]

注意，这里的 docstring 不只是给人看的注释，它会作为能力描述传给模型。我特意在 docstring 里加了“返回示例”，因为实测下来，模型根据示例理解返回结构的效率，远高于读一段字段说明。

接着定义“按成员统计工时”这个核心能力：

@mcp.tool() def get_work_hours_by_member( member_name: str, project_id: str, start_date: str, end_date: str ) -> dict: """统计指定成员在指定项目、指定时间范围内的总工时。 参数说明： - member_name: 成员姓名，必须是 list_projects() 返回的 owner 名称 - project_id: 项目编号，必须是 list_projects() 返回的 project_id - start_date: 开始日期，格式 YYYY-MM-DD - end_date: 结束日期，格式 YYYY-MM-DD，不能早于 start_date 返回示例： {"member_name": "张三", "total_hours": 28.5, "days": 4} """ # 实际实现需要查询工时系统，这里先返回模拟数据 if member_name not in ["张三", "李四"]: return { "error": "member 不存在，请先调用 list_projects() 获取有效成员列表" } return { "member_name": member_name, "total_hours": 28.5, "days": 4, }

这段代码里，我做了两个关键设计。第一，参数member_name明确写了它必须来自list_projects()的返回，这就相当于给模型指了一条路径：你要调这个工具之前，先得调另一个工具拿到合法的成员名。这是能力组合，不是单个函数能实现的。

第二，在函数内部我给了一个语义错误返回。如果模型传了一个无效成员名，返回的不是抛异常，而是一个带error字段的 dict——FastMCP 会把这个包装成正常的业务响应。模型收到后，会意识到“我用了无效参数”，从而主动转向调用list_projects()去问一次。

这就是协议设计里的“自纠错闭环”。

最后加上入口：

if __name__ == "__main__": mcp.run(transport="stdio")

3.3 本地联调：模型视角下它看到了什么

搭好 Server 之后，一定要本地测一遍。用 FastMCP 自带的调试客户端，或者直接用支持 MCP 的桌面客户端连接。

如果用 Cursor、Cline 这类客户端连接，你需要再补一段配置。以 Claude Desktop 风格为例：

{ "mcpServers": { "工时统计": { "command": "python", "args": ["path/to/your/server.py"] } } }

启动后，建议先做一个“能力发现测试”：随便问一句“你有几个能力，分别是什么”。这时候你站在模型视角，亲眼看一遍自己的能力被如何描述。我每次写新 Server 都会做这步，目的就是检查能力描述是否清晰。如果模型回答出来的是“我能查项目列表、能统计工时”，说明描述是合格的；如果它说“我能执行 Python 代码、能调用函数”这种啰嗦且不准确的话，说明 docstring 写歪了。

接着做“调用路径测试”：要求模型“统计张三在官网重构项目上周的工时”。如果模型能先调list_projects()拿项目 ID，再调get_work_hours_by_member()拿具体工时，说明能力组合链路通了。

这一步在实际使用中非常关键，能提前暴露很多注册问题。

3.4 写描述不是写注释，是写给模型读的说明书

这里单独提一条经验：MCP Server 里的 docstring，地位等同于面向用户的 API 文档，甚至要求更高。

因为调用你的不是程序员，而是一个大模型。它有强大的语义理解能力，但也会犯低级错误。如果描述模糊，它就会“发挥想象力”。我总结过几个描述法则：

第一个，参数描述必须给出“来源”。不要只写“project_id: 项目ID”，要写“project_id: 项目ID，可通过 list_projects 获取”。这能解决模型不知道参数值从哪来的问题。

第二个，返回结构必须给示例。模型看到 JSON Schema 能理解字段，但给一个具体示例，它能更准确地把结果映射到对话上下文中。我实测下来，模型自定义提示词时如果返回示例，用户体验明显更好。

第三个，要写明“何时不该调用这个工具”。比如“本工具只统计已归档项目的工时，未归档项目请用 get_work_hours_realtime”。负面约束对模型的纠错效果比我预期好很多。

3.5 再进一步：把资源和提示词也纳入能力设计

工具能覆盖的动作毕竟是有限的。有些信息适合以“资源”的方式接入，比如一份团队考勤规则、一个项目的人员清单。定义资源非常简单：

from fastmcp import Resource @mcp.resource("project://P001/members") def get_project_members() -> str: """官网重构项目的成员名单及角色。""" return "张三（负责人）、李四（前端）、王五（测试）"

模型在需要了解项目成员时，就能通过这个 resource URI 去读取。它和工具的区别是：工具会引起副作用（修改、统计），资源单纯就是查询给模型看。设计 Server 时，我会反复提醒自己：凡是“读背景信息”的，优先做成资源；凡是“执行动作”的，才做成工具。分清这两种原语，模型理解你的 Server 会容易得多。

Prompts 则适合更复杂的固定流程。比如，把“统计团队成员一周工时并生成周报”这个多步骤任务模板化，FastMCP 里定义 prompt，客户端可以直接引用。它像是一段可复用的“指令宏”，把多个工具调用按经验串起来。这样使用者在客户端里不再需要每次重新组织语言，直接选中那个 prompt 就行。

4. 接入侧视角：为什么模型工具列表经常“注册不上”

4.1 先查协议握手，再查配置路径

看完 Server 侧，再来看看 Client 侧，也就是 Cursor、Codex、Cline 这类工具连接 MCP 时遇到的那些事。

“工具注册不上”（也叫工具列表不刷新）是群里被问得最多的一个。其实这个问题的排查路径相对固定，先判断是协议层问题还是配置层问题。

协议层问题最典型的一个：Server 启动时崩溃了。MCP 多数走 stdio 传输，也就是客户端帮你启动一个子进程，通过标准输入输出通信。如果你的 Python 脚本里在if __name__ == "__main__"前多写了一个print()，那个意外输出就会污染标准输出信道，导致客户端解析失败。这种问题新手最容易踩，看起来像“工具没注册”，实际上进程压根没起来或者握手就断了。

我建议所有写 MCP Server 的人，第一步先做“裸启动测试”。在终端里手动跑一次你的启动命令，确保它能正常启动、不报错、不打印多余内容。你可以在命令行输一个假的 JSON-RPC 报文看它报什么错，但更快的办法是直接用官方 SDK 的调试工具，比如mcp dev或 Inspector 模式，它会同时显示客户端和服务端的收发消息。

4.2 描述写得太模糊，模型不会用

第二类注册问题其实“注册成功了，但调用失败”。很多人在日志里看到 Tools 数量是有的，但问模型“你能不能统计工时”，模型说“我找不到能统计工时的工具”。

这是最让人抓狂的情况，因为技术上一切正常。我曾经在给一个内部系统接 MCP 时，工具描述写的是“处理工时数据”，模型完全没意识到它就是用来统计工时的。后来我把描述改成“统计某成员在指定项目、指定日期范围内的总工时，返回总小时数和出勤天数”，模型立刻就会用了。

工具描述这件事，不是写给人看的，是写给模型“语义检索”用的。模型拿到几十个工具时，会基于当前用户的提问，在工具描述里做语义匹配。描述越贴近真实使用场景，匹配准确率越高。

这里我提供一个自查技巧：每写一个工具，都问自己三个问题——模型知道何时该调它吗？模型知道参数值去哪拿吗？模型知道返回结果怎么解读吗？三个问题有任何一个是“不知道”，就改描述。

4.3 典型问题排查清单

我把这段时间大家遇到的问题整理成一个速查表，按提示现象反查原因：

这个表我自己打印过一份贴在工位上，因为排查 MCP 报错时，最大的成本永远不是修复本身，而是判断“这是哪一层的问题”。

4.4 配置方法并不复杂，复杂的是心智模型

配置 MCP 其实非常简单，无非就是选一个传输方式（stdio 或 SSE/HTTP），填好启动命令，重启客户端。真正复杂的是接入方如何理解“工具不可用可能不是 bug，而是协议设计问题”。

举个实际例子，Figma MCP 在 Codex 里注册不上这个问题很典型。有人按教程把指挥服务配好，工具列表也出现了，但 Codex 就是“看不到”，反复报工具缺失。后来发现，Codex 对 MCP 工具是有缓存策略的，如果你在会话已经建立之后才启动 Server，它不会重新扫描。解法往往只是重新开启一个新会话，而不是改配置。

这种问题你很难通过阅读某个工具的官方文档解决，因为你面对的是“不同客户端对 MCP 协议实现差异”的问题。我对这类问题最深的体会是：MCP 生态现在还很早期，客户端五花八门，行为不统一，不要假设某个配置在所有客户端上行为都一样。遇到诡异问题时，第一反应应该是“换个会话试试”，第二反应才是去检查自己的 Server 代码。

4.5 多 Server 场景：注意工具名冲突和边界

当你同时接入了多个 MCP Server，比如一个数据库 MCP、一个目录文件 MCP、一个 Figma 设计稿 MCP，模型能同时看到所有 Server 的工具。这时候容易出现工具名冲突，比如两个 Server 都提供了search工具，模型就无法准确路由。

我在一个项目里同时接了 MySQL MCP 和 Elasticsearch MCP，结果两个都叫query，模型经常调错。解法是一方面在工具命名上加上前缀（mysql_query、es_query），另一方面在描述里把工具边界写清楚。对，我又要说描述的事了——宁可描述写得啰嗦，也不要让模型在两个相似工具之间反复横跳。

5. 边界辨析：MCP 与 Skill、Computer Use、多智能体的区别

5.1 MCP 是“能力供给”，Skill 是“做事方法”

聊 MCP 聊得越多，越多人开始问：MCP 和 Agent Skill 有什么区别？因为现在很多 Agent 产品都支持“Skill”或“技能”机制，比如你可以给某个 Agent 定义一个“周报生成技能”，它会自动读数据、画图表、生成邮件。那这跟 MCP 不就是一回事吗？

我的理解是：MCP 和 Skill 解决的是两个不同层面的问题。MCP 解决的是“模型能力的供给侧标准化”，它管的是如何把外部能力统一地接到模型面前，让模型会调用；Skill 解决的是“模型完成任务的方法论”，它往往包含了一套提示词模板、一系列操作流程、甚至多个 MCP 工具的组合方式。

打个比方，MCP 像是给厨师提供标准化的食材供应链——不管是中国菜、西餐、日料，食材的规格、品控、配送都有统一标准。Skill 则是菜谱——它解决的是“拿到食材之后，先切什么、再炒什么、最后怎么摆盘”。没有供应链，菜谱写得再漂亮也做不出菜；没有菜谱，食材再多也只是堆在厨房里。

换个更实际的角度：如果你发现自己在给 Agent 配置“先执行 A 工具，再判断结果，然后执行 B 工具”这种多步骤流程，你真正需要的也许是 Skill，而不是一个 MCP Server。反过来，如果你要给 Agent 新增一个它从未见过的能力来源，比如接一个从来没集成过的 BI 系统，你应该做的是写 MCP。

两者是互补关系。我在自己项目里的做法是：把每个外部系统都通过 MCP 做标准化接入，把每个高频业务流程做成 Skill 模板。模型需要做的是“理解我的 Skill 怎么编排”，而非“适配我的系统怎么连接”。

5.2 Computer Use 走的是另一条路：模拟人而非对接系统

另一个经常被拿来对比的概念是 Computer Use，Agent 直接操控电脑屏幕、移动鼠标、点击按钮，像人一样操作软件。很多人问：既然 MCP 能让 AI 接系统，为什么还要 Computer Use？

二者的哲学完全相反。MCP 的理念是“系统主动暴露接口，让 AI 高效对接”，System 层面需要改造配套；Computer Use 的理念是“不需要系统做任何适配，AI 直接模拟人操作界面”，本质是走人机交互的老路。

MCP 适合需要精确控制、复杂参数、高频调用的场景；Computer Use 适合没有 API、没有集成方案的旧系统。我自己的判断标线很简单：如果系统有 API，优先做 MCP，因为更稳、更快、可控性更强；如果没有 API，只能鼠标点点点操作，那 Computer Use 才有应用价值。

很多团队在落地时容易犯一个错误：在明明有完整 API 的系统上，非要训练 Agent 用 Computer Use 去模拟人工操作，结果速度慢、稳定性差、维护成本还高。这类需求本质上是“应该写 MCP 但懒得写”的问题，不是 Computer Use 的适用场景。

5.3 多智能体与 MCP：能力协议如何支撑协作

多智能体（Multi-Agent）也是这段时间的高频词。有人会把“一个模型加多个 MCP 工具”误认为多智能体，其实那只是单 Agent 的多工具调度。真正的多智能体协作，是多个各自独立的 Agent 分工合作：一个负责写代码、一个负责审查、一个负责测试、一个负责发布。

这类协作里，每个 Agent 都可能需要访问外部系统。如果每个 Agent 各自去对接一整套 API，那系统复杂度会指数级上升。MCP 在中间起的作用有点像“公共接口层”：每个 Agent 只要能连接 MCP Server，就自动获得了所有已注册能力，Agent 之间通过共享的能力边界互相协作。

举个例子，我的“客服知识库”项目里跑着一群 Agent：一个负责意图分类，一个负责知识检索，一个负责工单创建。它们围绕同一个 MCP Server 工作，这个 Server 提供了知识检索和工单写入两个能力。意图分类 Agent 判断完类型后，知识检索 Agent 调检索能力，工单创建 Agent 再调写入能力。这个架构里，每个 Agent 都是独立的，但能力调用是统一的。

所以，MCP 在单智能体场景里解决的是“一个大脑控制多只手”的效率问题；在多智能体场景里解决的是“多个大脑共用一套能力底座”的标准化问题。后者更接近我理解的“能力协议”终极形态。

6. 现在做 MCP 相关项目，有什么更值得关注的方向

关注完概念和实操，如果你已经决定切入 MCP 生态开发，现在有几个方向值得留意：面向场景的垂直 MCP、MCP 的沙箱与安全治理、还有能力组合的高级玩法。

先说垂直 MCP。现在的 MCP Server 大量集中在“给数据库加接口”“给浏览器加操作能力”这种通用场景。但真正让 MCP 产生价值的，往往是那些结合行业数据与工作流的定制化 Server。比如对接建筑行业的三维模型生成工具、对接设计稿标注系统、对接工业仿真软件。这类 Server 需要对行业有很深的理解，通用模型厂商不会做，需求却非常刚性。

然后是安全治理方向。随着接入的 MCP Server 越来越多，企业一定会面对权限管理、审计、异常检测的问题。MCP 协议虽然给了安全钩子，但如何在整个接入生命周期里做好治理，目前还处于灰色地带。这里面有机会做“MCP 网关”类的产品，在客户端和 Server 之间加一层统一管控，做工具鉴权、调用审计、敏感操作熔断。这不是单纯的技术问题，更是工程管理问题。

最后说说能力组合的玩法。MCP 的价值不止于单工具调用，更在于“几个工具组装成一个新流程”。比如文档解析 + 向量存储 + 语义检索三个 MCP 工具组合起来，就是一个 RAG 底层能力链路。如果你能理解“模型眼中看到的不是工具，而是能力”，那就能利用 Server 里的多工具编排，构建出复杂能力，而不是机械地写一个个孤立的函数。

我在选型时还有一条自己的原则：不要在项目里堆一大堆 MCP Server“以防万一”。能不加的就不加，因为每多一个 Server，模型的选择空间就会增加很多，误用率也会跟着涨。先加一个真正高频的核心 Server，跑顺之后再叠加下一个，比一次性接五个效果好得多。这套“少即是多”的思路，跟能力建模的目的一致——让智能体始终清楚该用什么、能做什么。

归根结底，MCP 值得我们认真对待，不是因为它多了一个协议，而是因为它第一次给“智能体如何获得并使用外部能力”提供了一个标准答案。你可能暂时不需要自己实现一个协议库，但至少在接入别人的 Server、或自己设计工具时，用“能力协议”的视角去审视，整个思路会通顺很多。