企业官网建设流程全解析

1. 从一个让人头大的问题说起：MCP、MCP 协议、MCP 服务、Tool 到底怎么区分

刚接触 MCP 这套东西的时候，我估计不少人和我一样，脑子里是一团浆糊。打开一篇讲 MCP 的文章，满屏都是“MCP 协议”“MCP 服务”“MCP Server”“Tool”“工具调用”这些词，看着好像都认识，但真要让你说清楚它们之间是什么关系，大部分人当场就卡壳了。更离谱的是，你去搜“MCP 是什么”，搜出来的结果一半在讲协议规范，一半在讲某个具体工具怎么接入，还有一堆是各种软件的 MCP 插件教程，信息完全不在一个层面上，越看越乱。

我自己最开始也是被绕进去的。当时想给手头的一个 AI 应用接一个外部能力，看到别人说“接个 MCP 就行了”，结果我连“接 MCP”到底是接协议、接服务还是接工具都没搞明白，折腾了大半天才理清楚。所以这篇东西我不打算写成那种干巴巴的规范解读，而是想用从业者之间聊天的口吻，把 MCP 这套体系里几个最容易混淆的概念彻底掰开揉碎讲清楚：MCP 协议是那套“通信规则”，MCP 服务是遵循这套规则对外提供能力的那个“服务端”，而Tool则是这个服务端具体暴露出来的、能被调用的一个个“功能点”。三者是层层嵌套的关系，不是并列的，更不是同义词。

搞懂这三者的区别，实际价值非常大。因为你在落地的时候，遇到的绝大多数问题——比如“为什么我的 AI 调不到这个工具”“为什么服务连上了但工具列表是空的”“为什么同一个工具在不同客户端表现不一样”——本质上都是因为你没分清问题出在哪一层。是协议握手没成功？是服务没起来？还是工具压根没注册进去？分清楚层次，排查效率能提升好几倍。这篇内容适合所有正在或准备把 AI 能力和外部系统打通的人看，不管你是刚入门的小白，还是已经接过几个服务但总觉得理解不透彻的老手，都能从中理出一条清晰的脉络。

下面我会按照“先讲清楚是什么、再讲清楚为什么这么设计、最后讲清楚怎么落地和怎么排错”的顺序展开，中间会穿插大量我实际踩过的坑和总结出来的经验，尽量让你看完之后，脑子里能有一张清晰的结构图，而不是一堆零散的词。

2. 先把概念钉死：MCP 协议、MCP 服务、Tool 的层次关系

2.1 用“餐厅”类比一次性讲透三者关系

要理解这三个概念，我最喜欢用的一个类比是餐厅。你把整个 MCP 体系想象成一家餐厅的运作模式，一下子就通了。

MCP 协议，就是这家餐厅的“服务规范”。比如客人怎么点菜、服务员怎么记录、后厨怎么接单、菜品怎么端上桌，这一整套流程和话术的约定，就是协议。它本身不是任何一道菜，也不是任何一个服务员，它只是一套“大家都要遵守的规则”。在技术层面，MCP 协议规定了客户端和服务端之间用什么格式通信、怎么发起请求、怎么返回结果、怎么描述一个工具的参数等等。它是一份“契约”，谁想参与这个体系，就得按这个契约来。

MCP 服务，就是这家餐厅本身，或者说餐厅的“后厨团队”。它是一个实实在在运行着的程序，遵循 MCP 协议对外营业。它负责管理自己有哪些菜（工具）、每道菜需要什么食材（参数）、做好了怎么端出去（返回结果）。你作为客人（客户端），是跟这个“服务”打交道，而不是直接跟协议打交道。协议是抽象的规则，服务是具体的实体。

Tool，就是这家餐厅菜单上的一道道具体的菜。比如“宫保鸡丁”“鱼香肉丝”，每一道菜就是一个 Tool。它是 MCP 服务对外暴露的最小功能单元。一个 MCP 服务可以只有一道菜，也可以有几十道菜。客户端真正调用的，永远是某个具体的 Tool，而不是笼统地“调用服务”。

所以三者的关系是：协议是规则，服务是遵守规则的实体，Tool 是实体对外提供的具体功能。你不可能“调用一个协议”，你调用的是服务里的某个 Tool，而这个过程遵循的是协议。这个层次一旦理清，后面所有的困惑基本都能迎刃而解。

2.2 为什么非要搞出“协议”这一层

很多人会问：我直接写个函数让 AI 调用不就行了，为什么还要搞一套协议出来？这个问题问得特别好，也是理解 MCP 价值的关键。

在没有统一协议之前，每个 AI 应用想接一个外部能力，都得自己写一套对接逻辑。A 应用接数据库是一种写法，B 应用接同一个数据库又是另一种写法，工具提供方要为每个客户端单独适配一遍，工作量巨大且极易出错。这就好比每家餐厅都自己发明一套点菜话术，客人进不同的店得学不同的说法，效率极低。

MCP 协议的出现，本质上是把“客户端怎么调用能力”和“服务端怎么提供能力”这两件事解耦了。只要双方都遵守同一套协议，客户端不需要知道服务端内部怎么实现，服务端也不需要知道客户端是谁。工具提供方只需要按协议实现一次，所有支持该协议的客户端都能直接用。这就是协议层的核心价值：标准化带来的复用。

从工程角度看，协议层还解决了几个很实际的问题。第一是能力发现，客户端连上服务后，能通过协议规定的方式自动问“你有哪些工具”，而不需要人工配置。第二是参数描述，每个工具需要什么参数、参数是什么类型、哪些是必填的，协议里都有统一的描述格式，客户端可以据此自动生成调用界面或校验逻辑。第三是结果封装，不管工具内部返回什么，最终都按协议规定的格式包装好再返回，客户端处理起来逻辑统一。这三点加起来，才让“即插即用”成为可能。

2.3 一张表看清三者的边界

为了让你更直观地记住区别，我整理了一张对照表，把三个概念在各个维度上的差异列清楚：

这张表建议你存下来，以后排查问题的时候对着看，先定位问题出在哪一层，再去深入，比盲目乱试高效得多。我自己的经验是，八成以上的“调不通”问题，最后都能归到这三层里的某一层，而且定位准了之后解决起来往往很快。

3. 深入 MCP 协议：它到底规定了些什么

3.1 协议的核心：请求、响应与能力描述

MCP 协议说到底，规定的主要是三类东西：怎么建立连接、怎么描述能力、怎么收发消息。这三件事构成了协议的主干。

建立连接这块，协议定义了客户端和服务端如何完成初始化握手。握手过程中，双方会交换各自支持的协议版本、能力范围等信息。这一步非常关键，因为如果版本对不上，或者某一方不支持对方要求的能力，连接就会失败。我遇到过好几次“服务明明起来了但客户端连不上”的情况，最后查出来都是握手阶段版本协商没通过。

能力描述这块，是 MCP 协议最有价值的部分之一。服务端需要按照协议规定的格式，把自己拥有的工具列表、每个工具的名称、描述、参数结构都“报”给客户端。客户端拿到这份描述后，就知道自己能调用哪些工具、每个工具怎么用。这个机制让整个体系具备了“自描述”能力，不需要人工维护一份工具清单。

消息收发这块，协议规定了请求和响应的具体格式。一次工具调用，本质上就是客户端发一个结构化的请求（包含工具名和参数），服务端执行后返回一个结构化的响应（包含结果或错误信息）。格式统一带来的好处是，客户端处理响应的逻辑可以高度复用，不用为每个工具单独写解析代码。

3.2 传输方式的选择与考量

协议本身是抽象的，但总得通过某种具体的传输方式来实现。常见的传输方式有基于标准输入输出的本地进程通信，也有基于网络连接的远程通信。选择哪种，取决于你的部署场景。

本地进程通信适合工具和服务在同一台机器上的场景，比如你给本地的开发工具接一个本地能力。这种方式延迟低、配置简单，但没法跨机器使用。网络通信则适合服务部署在远端、多个客户端共享的场景，灵活性强，但要考虑网络稳定性、认证授权等问题。

这里有个实操中很容易忽略的点：传输方式的选择会直接影响你的认证和权限设计。本地通信往往依赖操作系统层面的进程隔离，安全性由系统保证；而网络通信就必须自己考虑认证机制，否则任何能访问到地址的人都能调用你的工具。我在实际项目里就吃过这个亏，早期图省事没做认证，结果测试环境的服务被内部其他团队误调了一堆请求，虽然没造成损失，但也吓出一身冷汗。所以选传输方式的时候，一定要把安全方案一起想清楚，别等上线了再补。

3.3 协议版本兼容：一个容易被忽视的坑

协议是会演进的，不同版本之间可能存在不兼容的改动。这是所有做协议对接的人都绕不开的问题。MCP 协议也不例外，随着能力不断丰富，版本迭代是必然的。

实际落地时，我的建议是：在握手阶段就把版本校验做严格。客户端和服务端都应该明确声明自己支持的版本范围，协商出一个双方都支持的版本再继续。如果直接忽略版本、强行通信，很可能出现“看起来连上了，但某些字段解析不了”的诡异问题，排查起来非常痛苦。

另外一个经验是，如果你的服务需要同时支持多个版本的客户端，最好在服务内部做一层适配，把不同版本的请求统一转换成内部格式再处理。这样核心逻辑只需要维护一份，版本差异被隔离在适配层，维护成本会低很多。这个思路和做 API 版本管理是一样的，本质上是“对外兼容、对内统一”。

4. 拆解 MCP 服务：一个服务是怎么跑起来的

4.1 服务的生命周期：从启动到对外提供能力

一个 MCP 服务从代码到真正能对外提供服务，中间要经历几个阶段，理解这个过程对排查问题特别有帮助。

第一阶段是启动与初始化。服务进程启动后，会先加载配置、初始化内部依赖（比如数据库连接、外部 API 客户端等），然后注册自己拥有的工具。这个注册过程很关键，它决定了服务最终对外暴露哪些能力。如果某个工具因为依赖没准备好而注册失败，那它在客户端看来就是不存在的。

第二阶段是监听与握手。服务准备好之后，开始监听连接请求。客户端连上来时，双方完成协议握手，交换能力信息。这一步成功后，客户端才能拿到工具列表。

第三阶段是请求处理。客户端发起工具调用，服务接收请求、解析参数、执行对应逻辑、返回结果。这个阶段是服务真正“干活”的时候，也是问题最容易暴露的地方。

第四阶段是关闭与清理。服务停止时，需要正确释放资源、关闭连接，避免留下僵尸进程或占用端口。别小看这一步，我见过不少“服务重启后端口被占用”的问题，根源就是旧进程没清理干净。

4.2 工具注册：决定服务能力的关键环节

工具注册是 MCP 服务开发中最核心的一环，因为它直接决定了服务能干什么。注册一个工具，本质上就是告诉服务：“我有一个这样的能力，它叫这个名字，需要这些参数，调用后会返回这样的结果。”

注册时最容易出问题的地方是参数描述。参数的类型、是否必填、取值范围、默认值，这些信息如果描述得不准确，客户端就没法正确构造请求。我踩过的一个典型坑是：某个参数我标成了可选，但实际上内部逻辑强依赖它，结果客户端不传的时候服务直接报错。后来我把所有参数都老老实实按真实依赖关系标注，问题就没了。所以注册工具时，一定要让描述和实际行为严格一致，别图省事。

另一个经验是工具粒度要合理。一个工具干一件事，别搞成“万能工具”，参数一大堆、内部逻辑一堆分支。粒度太粗的工具，客户端很难用，参数稍微不对就报错，而且复用性差。反过来，粒度太细又会导致工具数量爆炸，客户端选择困难。我的做法是：按业务动作划分工具，一个工具对应一个明确的、可独立完成的操作，这样既清晰又好用。

4.3 服务的部署形态：本地、远程与混合

MCP 服务的部署形态直接影响你的架构设计。常见的有三种：纯本地、纯远程、混合。

纯本地部署，服务和应用跑在同一台机器上，通过本地进程通信。这种形态适合个人使用或单机工具，部署简单、延迟低，但没法共享。纯远程部署，服务独立部署在服务器上，多个客户端通过网络访问。这种形态适合团队协作或需要集中管理的场景，但要处理网络、认证、并发等问题。混合形态则是部分能力本地、部分能力远程，灵活但复杂度最高。

选择哪种形态，核心看两个因素：使用范围和敏感程度。如果工具只给一个人用、且涉及敏感数据，本地部署更稳妥；如果工具需要团队共享、且数据不敏感，远程部署更方便。我个人的建议是，先从本地形态起步，把工具逻辑跑通，再根据实际需求逐步迁移到远程。一上来就搞复杂的远程架构，很容易在还没验证核心价值的时候就陷进运维泥潭。

5. 认识 Tool：最小功能单元的设计与实现

5.1 一个 Tool 由哪些要素构成

一个 Tool 看起来只是“一个功能”，但它其实由好几个要素构成，每个要素都影响最终的使用体验。

首先是名称。名称要唯一、简洁、见名知意。我见过有人用拼音缩写命名工具，结果过两周自己都忘了是啥意思。名称是客户端选择工具的第一依据，一定要让人一眼看懂它是干什么的。

其次是描述。描述是给客户端（尤其是 AI）看的，它决定了 AI 能不能在合适的场景下选中这个工具。描述要写清楚“这个工具做什么、什么时候用、有什么限制”。写得含糊，AI 就可能该用的时候不用、不该用的时候乱用。这一点在 AI 驱动的场景下尤其重要，因为 AI 是靠描述来判断工具用途的。

然后是参数定义。每个参数的类型、含义、是否必填、默认值都要明确。参数定义得越清晰，调用出错的概率越低。

最后是返回结果。结果的结构要稳定、可预测。成功返回什么、失败返回什么，最好有统一的约定，方便客户端处理。

5.2 工具设计中的常见误区

做工具设计这些年，我总结出几个高频误区，几乎每个新手都会踩。

第一个误区是把工具当成内部函数的简单包装。内部函数可能依赖一堆全局状态、隐式上下文，但工具是暴露给外部的，必须自包含、无隐式依赖。直接把内部函数包一层当工具用，往往会在并发调用或跨会话调用时出问题。

第二个误区是参数设计过于技术化。工具的参数应该面向“使用意图”，而不是面向“内部实现”。比如一个查询工具，参数应该是“查询条件”，而不是“数据库连接串”这种内部细节。参数越贴近使用者的思维，工具越好用。

第三个误区是忽略错误处理。工具执行失败是常态，关键是怎么把失败信息清晰地返回给客户端。我见过不少工具出错时直接抛一个原始异常，客户端拿到一堆看不懂的堆栈，完全不知道该怎么办。好的做法是把错误分类、给出可读的提示，让调用方能据此判断是重试、改参数还是放弃。

5.3 工具与服务的边界：什么该放进服务，什么该做成工具

一个常见的困惑是：某个功能到底应该做成服务内部的一个模块，还是暴露成一个独立的 Tool？这个边界如果划不清，服务会变得臃肿或者工具会变得零碎。

我的判断标准是：看这个功能是否需要被外部独立调用。如果它只是服务内部某个工具执行过程中的一个步骤，那它就是内部模块，不需要暴露。如果它本身就是一个完整的、有独立价值的操作，外部可能单独调用它，那就做成 Tool。

举个例子，一个“订单管理”服务，内部可能有“校验订单合法性”这个步骤。如果它只在“创建订单”时被用到，那它就是内部模块。但如果外部也需要单独校验订单，那就可以把它也暴露成一个 Tool。核心原则是：对外暴露的是能力，对内封装的是实现。想清楚这一点，边界自然就清晰了。

6. 三者如何协同：一次完整的工具调用是怎么走通的

6.1 从客户端发起请求到拿到结果的完整链路

把三个概念都讲清楚之后，我们来看一次完整的调用是怎么走通的。这个过程理解了，你对整个体系的理解就闭环了。

第一步，客户端启动，根据配置找到目标 MCP 服务，发起连接。第二步，双方完成协议握手，协商版本和能力。第三步，客户端向服务请求工具列表，服务按协议格式返回自己注册的所有工具及其描述。第四步，客户端（或客户端背后的 AI）根据任务需求，从工具列表里选中一个合适的工具，按描述构造参数，发起调用请求。第五步，服务接收请求，解析出工具名和参数，找到对应的工具逻辑执行。第六步，服务把执行结果按协议格式包装好返回。第七步，客户端接收结果，解析后交给上层逻辑使用。

这条链路里，任何一步出问题都会导致调用失败。而排查的关键，就是先定位问题出在哪一步。是连接没建立？是握手失败？是工具列表为空？是参数构造错了？还是工具执行本身报错？每一步都有对应的排查方法，后面我会专门讲。

6.2 为什么理解链路对排查问题至关重要

我特别想强调这一点，因为它是区分“会用的”和“用得好”的分水岭。很多人遇到问题就一通乱试，改配置、重启服务、换客户端，运气好碰对了，运气不好折腾半天还是没解决。而理解链路的人，会先判断问题出在哪一环，然后有针对性地查。

比如“工具调不到”这个问题，可能的原因有很多：服务没起来、握手失败、工具没注册、工具名写错、参数不对、权限不足……如果你不理解链路，就只能一个个试。但如果你理解链路，你会先看连接状态，再看工具列表，再看具体调用，一层层缩小范围，很快就能定位。

我自己的习惯是，在服务里加详细的日志，把链路上每个关键节点都打上标记。连接建立、握手完成、工具列表请求、工具调用请求、执行结果，每个环节都有日志。这样一旦出问题，看日志就能立刻知道卡在哪一步。这个习惯帮我省了无数排查时间，强烈建议你也这么做。

6.3 一个容易混淆的点：工具调用和普通函数调用的区别

最后澄清一个很多人会混淆的点：MCP 里的工具调用，和我们平时写代码调函数，看起来都是“传参、执行、返回”，但本质上有很大区别。

普通函数调用是进程内的，调用方和被调用方在同一地址空间，共享内存和状态，调用是同步的、即时的。而工具调用是跨边界的，调用方和服务之间隔着协议和传输层，调用是异步的、可能失败的、有网络开销的。这个区别带来一系列影响：你不能假设工具调用是瞬时的，不能假设它一定成功，不能假设多次调用的顺序和时序，也不能在工具之间共享内存状态。

理解这个区别，能帮你避免很多设计上的想当然。比如，不要设计那种“先调工具 A 设置状态，再调工具 B 使用状态”的工具体系，因为跨边界调用不保证顺序和状态保持。每个工具都应该尽量自包含、无状态，需要状态的话显式通过参数传递。这是跨边界调用设计的基本原则。

7. 实操落地：从零搭一个最小可用的 MCP 体系

7.1 环境准备与依赖梳理

讲了这么多概念，该动手了。这一节我带你把一个最小可用的 MCP 体系搭起来，让你真正感受一下三者是怎么协同的。

先说环境准备。你需要的东西其实不多：一个能跑服务的运行环境（比如常见的脚本语言运行时）、一个支持 MCP 协议的客户端、以及一个你想暴露的能力。我建议第一次实践时，选一个最简单的能力，比如“查询当前时间”或者“做个加法”，别一上来就搞复杂的数据库查询，那样容易在环境问题上卡住。

依赖梳理这块，核心是搞清楚你的服务需要哪些外部依赖。如果工具逻辑依赖某个外部 API，那服务启动前要确保这个 API 可达；如果依赖某个本地库，要确保库已安装。我踩过的坑是：服务启动时没检查依赖，等客户端调用工具时才报错，排查起来绕了一大圈。后来我改成服务启动时就做依赖自检，依赖不可用就直接启动失败并给出明确提示，问题定位快多了。

7.2 编写一个最简单的 Tool 并注册到服务

下面用一个“加法工具”作为例子，演示工具的定义和注册。这里用伪代码风格说明，具体语言按你的技术栈替换。

# 定义工具的处理逻辑 def add_numbers(a, b): return a + b # 注册工具，描述它的名称、参数和用途 register_tool( name="add_numbers", description="计算两个数字的和，适用于需要做加法的场景", parameters={ "a": {"type": "number", "required": True, "description": "第一个加数"}, "b": {"type": "number", "required": True, "description": "第二个加数"} }, handler=add_numbers )

这段代码看起来简单，但每个部分都有讲究。名称用了下划线命名，清晰表达意图；描述写明了用途和适用场景，方便 AI 判断；参数定义明确了类型和必填性；handler 指向实际的处理函数。这就是一个规范的工具注册。

注册完成后，启动服务，服务就会在握手时把这个工具报给客户端。客户端拿到后，就能调用它了。第一次跑通这个流程，你会对“协议、服务、工具”三者的协同有非常直观的感受。

7.3 客户端连接与调用验证

服务起来之后，用客户端连上去验证。连接时要注意几个点：地址和端口要对，传输方式要和服务端一致，认证信息（如果有）要正确。连上之后，先看能不能拿到工具列表，这是验证服务是否正常工作的第一步。

拿到工具列表后，找到你注册的那个工具，按参数定义构造一次调用。如果返回了正确结果，恭喜你，最小闭环跑通了。如果没跑通，别急，按下一节的排查方法一步步来。

我建议第一次实践时，把每一步的输出都打印出来：连接状态、握手结果、工具列表、调用请求、调用响应。这样一旦某一步不对，你能立刻看到。等熟练了再精简日志。这个“先啰嗦后精简”的过程，是掌握任何新体系的必经之路。

8. 常见问题与排查技巧实录

8.1 连接类问题：连不上、超时、握手失败

连接类问题是最常见的，表现是客户端根本连不上服务，或者连上了但握手失败。

连不上，先查三件事：服务是否真的在运行、地址端口是否正确、网络是否可达。我遇到过好几次“服务没起来但以为起来了”的情况，尤其是后台启动的服务，进程可能已经挂了但没注意。所以第一步永远是确认服务进程状态。

超时，通常是网络问题或服务响应太慢。如果是本地通信，超时很少见，出现的话多半是服务卡死了。如果是远程通信，要检查网络延迟和服务负载。我处理过一个案例，服务本身没问题，但因为某个工具执行时卡在一个慢查询上，导致整个服务响应变慢，其他请求也跟着超时。后来把慢操作做了超时控制，问题就解决了。

握手失败，基本是协议版本或能力协商的问题。查一下双方声明的版本范围有没有交集，以及客户端要求的能力服务端是否支持。这类问题日志里通常有明确提示，仔细看日志基本能定位。

8.2 工具类问题：列表为空、调用报错、结果异常

工具类问题出在服务已经连上、但工具用不了的情况。

工具列表为空，说明服务没有成功注册任何工具，或者注册了但没正确上报。先查服务日志里工具注册那一步有没有报错，再查握手时能力上报是否正常。我遇到过一次，工具注册代码写在一个条件分支里，某个配置没开导致分支没进，工具压根没注册。这种问题看日志一眼就能发现。

调用报错，原因就多了：工具名写错、参数类型不对、参数缺失、工具内部逻辑异常。排查时先确认工具名和参数是否和描述一致，再看服务端日志里具体的错误信息。我的经验是，大部分调用报错都是参数问题，尤其是类型不匹配和必填项缺失。

结果异常，指的是调用成功了但返回的结果不对。这通常是工具内部逻辑的问题，需要检查工具实现。也有可能是参数虽然类型对但语义不对，比如传了个负数给只接受正数的参数。这类问题要靠完善的参数校验和清晰的错误提示来预防。

8.3 排查速查表与独家避坑经验

为了让你排查时有个抓手，我把常见问题整理成一张速查表：

最后分享几个我踩坑总结出来的经验。第一，日志要打全，但要有层次，关键节点用高等级日志，细节用低等级，排查时按需开启。第二，参数校验要在服务端做，别指望客户端一定传对，服务端自己校验一遍最稳妥。第三，工具要尽量无状态，跨边界调用不保证状态保持，有状态的设计迟早出问题。第四，版本兼容要提前规划，别等客户端升级了才发现服务不兼容。这几条看起来简单，但真正做到能省下大量排查时间。

9. 我个人的一些实践体会

聊了这么多概念、设计和排查，最后说点我自己的真实感受。MCP 这套体系刚接触时确实容易懵，因为它的概念层次比一般的“调个接口”要复杂一些。但一旦你把“协议、服务、工具”这三层关系理顺了，后面的一切都会变得顺理成章。我现在看任何一个 MCP 相关的问题，第一反应都是先判断它属于哪一层，这个思维习惯帮我省了太多时间。

另外一个体会是，别急着上复杂架构。我见过太多人一上来就想搞远程服务、多客户端共享、复杂认证，结果核心功能还没跑通就陷在运维里了。正确的顺序应该是：先用最简单的本地形态把工具逻辑跑通，验证价值，再根据实际需求逐步加复杂度。技术选型永远服务于实际需求，而不是反过来。

还有一点，工具的描述和参数设计，值得你花比写逻辑更多的时间去打磨。因为工具是给人（和 AI）用的，好不好用很大程度上取决于描述清不清晰、参数合不合理。我见过功能很强但没人愿意用的工具，问题就出在描述含糊、参数反直觉。反过来，一个简单的工具如果描述到位、参数友好，用起来会非常顺手。这个道理，做过工具的人都懂。

如果你正在搭自己的 MCP 体系，我的建议是：先把这篇里的三层关系图在脑子里建起来，然后从一个最小工具开始动手，跑通之后再逐步扩展。遇到问题就按层次去定位，别乱试。这套方法我用了很久，实测下来很稳。