MCP 入门：把你的服务变成可插拔工具（Server/Client 思维）

MCP 解决的核心问题：工具不该“强绑定”在某个 Agent 里

当你开始写多个 Skill 或多个 Agent，你会遇到重复劳动：

• 每个项目都要接一次同样的工具（GitHub、数据库、搜索）
• 每个项目的权限与参数校验各写一遍
• 工具升级时，所有项目都要同步改

把工具“协议化”，就是把这些成本集中处理。

你可以把 MCP 当成什么

• 一个“工具服务层”：对上提供标准化 tools，对下对接真实系统
• 一个“可插拔工具市场”的接口：不同 tool server 可被不同 client 复用

具体协议细节你可以先不深挖，先抓住工程化收益：解耦、复用、可审计。

Server/Client 思维：先想清楚职责边界

建议按下面方式拆分责任：

• MCP Server：提供 tools 列表、schema、执行、权限控制、审计
• Client（Skill/Agent）：只关心“要用什么工具”以及“如何消费工具结果”

这样做的好处是：Skill 变轻、工具变稳。

最小 MCP Tool 的设计要点

无论你用什么语言实现 server，都建议遵守以下工程化约束：

• 明确 schema：输入字段、必填、范围、拒绝未知字段
• 权限最小化：server 侧强制权限，client 侧只声明意图
• 可审计：每次调用都打 trace 字段（后面会讲）
• 可降级：外部系统不可用时返回结构化错误与可重试标记

动手做：用 MCP 拆出你的第一个“工具服务层”

你可以从一个只读工具开始（最安全、最容易跑通）：

• github.get_pull_request
• repo.search_code
• docs.get_page

做法建议：

1. 先写 tool spec（name/description/input_schema/permissions）
2. 再写执行器：把输入映射到真实 API
3. 最后加审计：记录 input/output/error/latency

当你能稳定提供“只读工具”，再考虑写工具与人类确认点。

工程化清单

• 工具与 Skill 解耦：Skill 不直接依赖具体 API 细节
• 工具 schema 与权限在 server 侧强制执行
• 工具调用可审计且可统计（成功率、延迟、错误类型）

常见坑

• 把 MCP 当成“万能框架”：先解决复用与审计，别急着上复杂编排
• server 不做权限控制：等于把风险外包给模型
• schema 不严格：幻觉参数会导致不可预期行为

下一篇：把 Skill 连到真实世界：连接器模式与稳定性策略。