从零搭建MCP服务器：Claude工具调用实战教程

MCP 是什么：Anthropic 的开放标准

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 发布的一套开放标准，用于让大语言模型与外部工具、数据源建立标准化的连接。它的核心价值在于把 Claude 这类模型从「只会生成文字」升级为「能够调用真实函数、获取真实结果」的智能体。

整个协议由三层构成：

• MCP Host（宿主）：用户直接交互的应用，比如 Claude Desktop 或你自己开发的客户端。
• MCP Client（客户端）：运行在 Host 内部，负责管理协议与连接。
• MCP Server（服务器）：一个轻量级进程，用来编写工具并对外暴露。

在这三层之上，MCP 定义了三种核心原语（primitives）：Tools（工具） 是 Claude 可以调用的函数；Resources（资源） 是 Claude 可以读取的只读数据；Prompts（提示） 是预置的提示模板。本文教程聚焦在最实用的一环——如何自己动手写一个工具并接入 MCP Server。

MCP 的设计灵感来自语言服务器协议（LSP，Language Server Protocol）——同样是通过标准化接口解耦「能力提供方」与「能力消费方」。在 MCP 出现之前，让模型调用外部工具通常依赖各家平台私有的 Function Calling 实现（如 OpenAI 的 tool_calls 格式），工具代码与特定 API 强绑定，换个模型或平台就要重写适配层。MCP 的价值在于把这层接口标准化：只要服务器遵循协议，同一个工具可以被任意兼容 MCP 的客户端调用，实现「一次编写，多处复用」。协议底层使用 JSON-RPC 2.0 作为消息格式，支持 stdio（标准输入输出）和 SSE（Server-Sent Events）两种传输方式，前者适合本地进程通信，后者适合远程 HTTP 场景。

一次工具调用的完整链路

理解 MCP 的关键，是搞清楚一条消息在系统内是怎么流转的。UP 主用「东京天气如何」这个经典例子拆解了整个请求周期：

1. 用户向 Host 发送消息「What is the weather in Tokyo」。
2. Claude 识别出这需要调用工具，返回的不是文字，而是一个 tool use（工具调用）响应。
3. Host 应用根据响应去调用对应函数（如 get_weather），并把问题中的参数传进去。
4. MCP Server 执行真实业务逻辑，返回结果。
5. Host 把结果作为 tool result 再发回给 Claude。
6. Claude 基于真实结果生成最终面向用户的答案。

这个「请求—工具调用—工具结果—响应」的循环，正是 MCP 与普通对话最本质的区别：模型不再凭空编造答案，而是通过标准协议拿到真实数据后再作答。

定义工具 Schema：告诉 Claude 工具能做什么

要让 Claude 知道有哪些工具可用，必须用 JSON Schema 描述每个工具。Schema 包含三个关键部分：

• name：工具名称
• description：工具功能的自然语言描述，Claude 靠它判断何时调用
• input_schema：输入参数的类型与约束

教程中以一个计算器工具作为示例。它的描述写成「perform calculation operations」，支持加、减、乘、除四种运算。在 input_schema 里定义了三个属性：operation（类型为字符串，用 enum 限定为 add / subtract / multiply / divide）、a 和 b 两个操作数，并把三者都设为 required（必填）。

这里的 enum 约束是个细节亮点：它把运算类型限定在四个合法值内，既降低了 Claude 传错参数的概率，也让 Schema 本身承担起了一部分校验职责。描述文字写得越清晰，Claude 选对工具、传对参数的准确率就越高。

JSON Schema 是一套描述 JSON 数据结构的规范，最初由 IETF 标准化，被广泛用于 API 文档、表单校验和配置验证。在 MCP 的语境中，它承担着「函数签名」的角色——告诉模型这个工具接受什么类型的输入、哪些字段是必填的、字符串的合法取值范围是什么。type 字段指定数据类型（string、number、boolean、array、object），enum 字段列举所有合法枚举值，description 字段则用自然语言解释每个参数的含义。模型在决策「要不要调用这个工具、该传什么参数」时，主要依赖的正是这些描述文字，而非执行过任何实际代码。因此，写好 description 的重要性不亚于写好代码逻辑本身——模糊的描述会直接导致模型选错工具或传入不合法的参数值。

实现工具逻辑与异常处理

Schema 只是「说明书」，真正干活的是处理函数 handle_calculator。根据 operation 的取值走 if-else 分支：add 返回 a + b，subtract 返回 a - b，multiply 返回 a * b，divide 返回 a / b。

值得学习的是除法分支里加入的异常处理：当 b 为 0 时，直接抛出「division by zero is not allowed（除以零不被允许）」的错误，而不是让程序崩溃。这个设计后面在边界测试中会派上用场。

调度循环：让 Claude 自主决定调用哪个工具

工具准备好后，需要一个**调度循环（dispatch loop）**把整个 MCP 周期串起来。首先建立工具注册表（tool registry），把 calculator 工具和 handle_calculator 处理函数登记进去。

接着构建 agentic loop（智能体循环）：这个函数把消息发给 Claude，处理它发起的任何工具调用，并持续循环，直到 Claude 返回最终文字答案。循环中有两种情况：

• 情况一：Claude 想调用一个或多个工具，则执行工具并把结果回传，继续循环。
• 情况二：Claude 返回最终文字答案，循环结束。

模型配置中指定了使用的 Claude 模型、最大 token 数，并把工具 Schema 和历史消息一并传入。这种循环结构是构建任何 Agent 的通用骨架——只要工具会被多次调用，就离不开它。

Agentic loop（智能体循环）本质上是一个「感知—决策—执行」的反复迭代过程，与强化学习中的 agent-environment 交互模式高度对应。在实现层面，循环的终止条件通常有两种：模型返回纯文本响应（stop_reason 为 end_turn），或达到预设的最大迭代次数安全上限（防止工具调用出错时陷入死循环）。多轮工具调用时，每次工具执行的结果都会作为新的 tool_result 消息追加到对话历史中，模型在下一轮推理时可以「看到」所有已执行的工具结果，这是链式计算能够成立的根本原因——模型并不在内部记忆中保留中间值，而是从对话上下文中读取前序步骤的输出。这也意味着上下文窗口的大小实际上限制了 agentic loop 所能支持的最大推理深度。

三类测试：验证工具真的能用

教程用三个层层递进的测试来验证成果，这也是评估 MCP 工具是否可靠的实用方法。

单次算术调用

提问「What is 347 × 58」，Claude 正确识别出 operation 为 multiply，提取出参数 a 和 b，发起工具调用，拿到 tool result 后生成最终答案。整个 tool call → tool result → 最终响应的链路清晰可见。

链式计算

这是更能体现 Agent 能力的场景：「如果我每月赚这么多，35% 花在房租上，付完房租还剩多少？」

Claude 先调用 multiply 算出房租金额（例如 1487.5），再调用 subtract 用月收入减去房租，得到剩余金额。也就是说，Claude 多次调用同一个工具并把上一步结果作为下一步输入，完成了推理链条。这正是 agentic loop 存在的意义。

边界情况

提问「What is 100 divided by 0」，Claude 调用 divide 工具，触发了此前写好的异常处理，tool result 返回「error: division by zero is not allowed」。有意思的是，Claude 不仅把错误如实反馈，还额外解释了「数学上为何不允许除以零」——展现了工具结果与模型推理的协同。

小结：MCP 工具开发的关键要点

这套教程用一个计算器工具，完整走通了 MCP Server 自定义工具的开发流程。回顾整个过程，几个环节最值得记住：Schema 描述决定了 Claude 能否正确选工具，异常处理决定了工具的健壮性，而 agentic 调度循环则是支撑链式调用与复杂推理的核心。掌握这套模式后，把计算器换成天气查询、数据库读取或任意业务逻辑，方法都是一样的。