第 2.7.1 节：把 MCP Server 设计成可复用的工具服务
MCP Server只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够按顺序说明 MCP Server 的触发、处理、复核、记录和兜底步骤。
本章要解决什么问题
第 2.6 章已经讲过 MCP（模型上下文协议） 的基础：它让 AI（人工智能）应用用更标准的方式连接外部工具、资源和上下文。那一章重点解决“为什么需要 MCP”“MCP 和 Tool Calling（工具调用） 有什么关系”“MCP Client（模型上下文协议客户端）和 MCP Server（模型上下文协议服务端）分别是什么”。
本章往前走一步，讲制作方法。
在“企业客服知识库与工单 Agent（智能体）工作台”里，我们希望把一批客服能力做成可复用的 MCP 能力：
search_policy：搜索售后政策、退换货规则、服务条款。get_order：查询当前客户的订单、物流和售后状态。create_ticket：在用户确认后创建客服工单。get_customer_profile：查看客户资料、等级、历史工单摘要和风险标签。
如果只是把这几个名字写进工具列表，项目仍然不可交付。真实系统还必须回答：
- 这些工具由哪个 MCP Server（模型上下文协议服务端）暴露？
- 每个工具的 tool card（工具卡）怎么写，模型才能正确理解？
- 哪些 Resources（资源）用 resource card（资源卡）暴露，哪些只允许工具内部读取？
- 哪些 prompt template（提示模板）可以由服务端提供，哪些应该留在客户端？
- MCP Client（模型上下文协议客户端）如何根据当前用户、角色、会话和风险筛选工具？
- 谁来做 auth（认证授权）？
- 每次发现、调用、拒绝、审批和失败如何进入 audit（审计）？
本章最重要的一句话是：MCP Server（模型上下文协议服务端）负责暴露 tools（工具模块）/resources/prompts（工具/资源/提示模板），MCP Client（模型上下文协议客户端）负责发现、筛选、授权、调用和处理结果。Server 暴露工具，Client 决定哪些工具在当前会话可用。
这句话要贯穿整章。新手最容易犯的错误，是以为“服务端有这个工具，模型就可以用”。企业项目不能这样做。服务端只是声明和提供能力；真正进入某个会话之前，客户端还要结合当前身份、角色、业务对象、风险等级、审批状态和工具白名单做最后裁剪。
本章用流程图、字段契约表、权限状态表、失败兜底表和面试回答，讲清一个可交付 MCP 服务端和客户端应该怎么设计。
学习目标
学完本章后，读者应该能做到：
- 用人话解释 MCP Server（模型上下文协议服务端）和 MCP Client（模型上下文协议客户端）的职责边界。
- 说清“Server 暴露工具，Client 决定当前会话可用工具”的工程原因。
- 为
search_policy、get_order、create_ticket、get_customer_profile设计 tool card（工具卡）。 - 为政策文档、客户资料摘要、工单分类说明设计 resource card（资源卡）。
- 设计一个 prompt template（提示模板），让客服 Agent 按统一方式总结投诉、解释政策或创建工单前确认用户意图。
- 设计 MCP 制作中的字段契约，包括服务端编号、客户端编号、工具名称、权限范围、认证上下文、风险等级、审批要求、审计字段、追踪编号和传输模式。
- 区分本地 stdio（标准输入输出）传输和远程 HTTP（超文本传输协议）传输的适用场景。
- 设计工具发现、权限过滤、工具调用、结果处理和审计日志的完整流程。
- 识别服务端不可用、工具发现过宽、资源越权、写入重复、审批缺失等失败场景，并给出兜底。
- 把本章内容连接到后续 LangGraph（智能体状态图框架）、安全权限、可观测性和作品集项目。
- 回答至少 10 个关于 MCP Server（模型上下文协议服务端） / Client 制作的面试追问。
贯穿业务场景
本章继续使用同一个贯穿项目：企业客服知识库与工单 Agent 工作台。
这个工作台面向 4 类人：
| 角色 | 典型需求 | 可以使用的能力 |
|---|---|---|
| 普通客户 | 查询订单、了解售后政策、提交问题 | 查政策、查本人订单、创建本人相关工单 |
| 一线客服 | 查看客户资料、处理工单、解释政策 | 查政策、查订单、查客户资料摘要、创建和补充工单 |
| 客服主管 | 查看团队质量、复盘高频投诉 | 读取报表资源、查看工单聚合数据、查看质检规则 |
| 运营人员 | 更新政策、维护知识库、分析问题趋势 | 读取和维护知识库资源、查看反馈和统计 |
为了让多个 Agent 应用复用这些能力，我们把系统拆成若干 MCP Server（模型上下文协议服务端）：
| MCP Server（模型上下文协议服务端） | 暴露的工具 | 暴露的资源 | 不应该做什么 |
|---|---|---|---|
| 政策 MCP Server（模型上下文协议服务端） | search_policy | 售后政策、退换货规则、服务条款 | 不判断订单归属，不创建工单 |
| 订单 MCP Server（模型上下文协议服务端） | get_order | 订单状态说明、物流状态说明 | 不直接退款，不返回他人订单 |
| 工单 MCP Server（模型上下文协议服务端） | create_ticket | 工单分类、处理时效、投诉规则 | 不绕过用户确认，不自动关闭投诉 |
| 客户 MCP Server（模型上下文协议服务端） | get_customer_profile | 客户资料摘要、历史工单摘要 | 不暴露完整隐私资料，不越权查看 |
客服工作台本身是 MCP Client（模型上下文协议客户端）。它连接这些服务端，获取可用工具和资源，但不会把所有工具直接交给模型。它会先看当前会话：
- 当前用户是否登录。
- 用户是客户、客服、主管还是运营。
- 当前会话是否已经完成身份校验。
- 当前问题是否和某个订单或工单相关。
- 当前工具是否只读、写入或高风险。
- 是否需要用户确认或人工审批。
- 这次调用是否能记录审计追踪。
只有通过这些过滤后，工具才会进入当前 Agent 会话。换句话说，MCP Server（模型上下文协议服务端）像企业内部能力货架；MCP Client（模型上下文协议客户端）像工作台里的值班经理，决定这次会话能从货架上拿哪些能力。
新手为什么会卡住
MCP 制作看起来像“写服务端、连客户端、调用工具”，但新手真正卡住的地方通常不是连接，而是边界。
| 常见卡点 | 问题在哪里 | 正确理解 |
|---|---|---|
| 服务端有工具，模型就能用 | 把服务端暴露和当前会话可用混为一谈 | Server 暴露候选能力，Client 按身份、场景、权限和风险筛选。 |
| tool card（工具卡）就是工具描述 | 只写一句描述，缺输入、输出、风险、审批和审计 | 工具卡是模型、客户端和审计共同理解工具的契约。 |
| resource card（资源卡）只是文件路径 | 忽略资源权限、版本、敏感级别和引用方式 | 资源卡要说明谁能读、读什么范围、能否引用给用户。 |
| prompt template（提示模板）可以替代业务规则 | 把提示词当安全边界 | 提示模板只规范表达和任务步骤，不能代替权限、审批和后端规则。 |
| auth（认证授权）交给模型判断 | 模型无法可靠校验身份和对象归属 | 认证授权必须在系统层完成，模型只能收到允许使用的工具。 |
| audit（审计）等出事再补 | 没有审计就无法复盘工具发现、选择和调用 | 发现、调用、拒绝、失败、审批都要有 audit_trace_id（审计追踪编号）。 |
| 远程 MCP 等同普通 API（应用程序接口） | 忽略 AI 客户端的工具发现和上下文暴露需求 | MCP 面向 Agent 应用，需要工具说明、资源说明、权限上下文和结果处理。 |
| 工具越多越强 | 模型选择混乱，权限面扩大 | 工具要按会话裁剪，低相关工具不进入当前可用列表。 |
本章要拆掉这些误解。一个 MCP 项目是否成熟，不是看“能不能连上”，而是看它是否能控制：谁看见了什么工具，为什么能调用，调用后如何解释，失败后如何兜底，出问题后能不能追溯。