基础篇

F25｜工具与MCP：连接、发现、授权、执行四层拆开

基础篇约 2.9 千字1 组分步图解

从具体对象与小例子开始，理解计算过程与适用条件。

本节会用到

F22 · Agent不是另一个神经网络 F23 · API与流式协议 F24 · 状态、事件与检查点

本章目录

动态图解 · F25

MCP连起接口，不自动交出权限

连接、发现、模型可见和实际授权分别发生在哪里？

把MCP想成工具之间的共同接口语言，而不是新大脑。Host负责应用级选择与控制，Client负责协议连接，Server提供能力。接线完成以后仍要决定哪些工具暴露给模型、哪些资源允许访问、哪些动作需要确认。

Host承载模型、任务与权限策略的应用。

ClientHost中的协议客户端。

Server提供工具、资源等能力的服务。

授权允许某个身份在某个范围执行某个动作。

输入与适用条件：按公开架构画逻辑流程，省略具体传输和认证字段。不同协议版本的能力细节以项目声明为准。

1 / 7 · 1. Host建立连接，Client与Server协商能力

停留时间

步骤第1步，共7步

窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。

Host是承载AI应用的宿主；Client是其连接特定Server的协议客户端。建立连接不是自动批准所有操作。

本步状态由图形与说明共同给出。

默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。

为什么需要

减少每个工具都单独设计集成方式的成本。

怎样实现

先发现能力，再由宿主形成模型可见集合，最后在执行边界检查权限。

可能的代价与误解

外部Server的权限不会因为本地Shell受沙箱保护而自动受同样限制。

如何判断是否做对

分别测试“未暴露”“未授权”“参数不合法”“业务拒绝”，观察是否被准确区分。

先别把MCP理解成“给模型装了一个新大脑”

MCP（Model Context Protocol）规定AI应用与外部能力之间怎样通信。它帮助统一工具、资源等能力的描述和交互，不直接训练模型，也不会自动赋予无限权限。

Host是用户使用的宿主应用；Client是宿主内部与某个服务连接的协议参与者；Server提供工具或数据能力。例如编辑器是Host，内部MCP Client与代码搜索Server交互。

这里server不是一定在远方大机房，也可以是本机进程。谁连接谁、用哪种传输方式，是具体部署选择。

一次从连接到工具结果的逻辑次序

先建立连接，初始化并确认兼容的协议和能力；随后请求工具列表或其他能力说明；宿主把适合本任务的工具描述提供给模型；模型提出调用；宿主检查授权并发给服务；服务执行并返回结果；宿主再回填给模型。

这不是一个步骤。工具存在于服务端，不等于已经被发现；被发现不等于暴露给当前模型；暴露不等于本用户有权执行；调用返回也不等于业务目标已完成。

Tools、Resources、Prompts各是什么

Tool是可执行操作，例如search_code(query)；Resource是可供读取的数据或内容，例如某份说明文档；Prompt是服务提供的可复用消息模板。它们在协议中有不同角色，不能因为都能影响上下文就认为可以互换。

Skill通常是任务流程和相关资源的组织单位。Skill可能教Agent什么时候调用一个Tool，但Skill本身不天然获得操作系统权限。

工具Schema不应替代业务判断

工具描述要说清输入、输出、前提、错误和副作用。“处理项目”这样的大而模糊能力，容易让模型不知道具体能做什么；把每个微小动作拆成几十个工具，也会增加调用和上下文成本。

一个适度边界的接口可以同时返回文件片段、版本和下一段位置，减少“搜到了但不知道属于哪个版本”的问题。工具输出是否适合模型读取，是接口设计的一部分，不是只满足程序类型就够了。

stdio、HTTP与JSON-RPC先只懂职责

stdio指通过进程标准输入输出通信；如果协议消息走stdout，普通调试日志混在其中可能破坏解析。HTTP是常见网络请求协议；MCP可在具体版本约定下使用适合的传输。

JSON-RPC是一种用JSON表达远程方法、参数、请求标识与结果/错误的调用约定。它解决消息组织，不自动解决身份认证和操作幂等。

系统篇按照注明的协议版本说明具体生命周期。新版本字段会改变，所以阅读时区分稳定职责与版本特定细节。

身份、认证和授权

认证authentication是确定“你是谁”；授权authorization是决定“你能做什么”。连接成功不等于已经获准读取每份数据。

OAuth scope可以理解为一类授予访问范围的声明，但具体资源仍可能有自己的访问限制。最小权限要求只给完成当前任务必要的能力，而不是为了避免报错直接给全部权限。

工具说自己read-only也不能代替独立安全判断。服务端实现和宿主边界都可能存在错误，需要按风险验证。

子Agent为什么不一定继承全部工具

子Agent可能拥有独立上下文、不同工具白名单或连接配置。主Agent知道一个MCP服务，不代表子Agent自动收到它的工具说明或执行权。

排查应沿发现、暴露、授权、调用、返回逐层看。只在Prompt里反复写“你应该能用工具”，无法修复实际未配置的能力。

运行示例 · F25

把一个MCP读取请求分成四道不同关口

输入与条件。连接一个只提供 read_note(name) 的教学MCP服务。固定使用2025-06-18协议快照，避免把示例当所有版本都相同。

步骤与对象	内部动作	中间结果 / 新状态
1连接并初始化	客户端发initialize，服务端返回协议版本与能力	两端先同意怎样通信。
2确认就绪	客户端发notifications/initialized	这是通知，没有请求id。
3发现工具	发tools/list	返回read_note及参数schema；发现不等于获准读取所有笔记。
4做授权	宿主确认用户只能读project-A	name来自模型也不能绕过范围检查。
5执行并关联结果	发tools/call，返回对应请求id的结果	执行成功后再把内容交给模型。

把过程连起来。连接、发现、授权、执行互不替代。能在列表看见工具不代表一定能调用，也不代表子Agent继承同样权限。

边界与反例。请求顺序参照固定官方规范；笔记工具为原创，没有声称某个服务实际提供这个名称。

依据与适用范围：[MCP-LIFE] [MCP-TOOLS]。示例输入和场景由本书明确设定。

课后自检

自检 1

服务端已有search工具，模型一定知道吗？

查看参考答案收起参考答案

不一定。还需发现并由宿主向本轮模型暴露适当说明，同时检查授权。

自检 2

认证通过就能读取所有文件吗？