MCP 概述
灵渠作为 MCP 网关，把分散的外部工具服务器聚合成单一工具入口，并让每一次工具调用同样经路由、缓存检查点、安全护栏中间件管道统一治理
灵渠在统一查询入口之外，还提供一层 MCP 网关能力。MCP（Model Context Protocol，模型上下文协议）是一项面向工具调用的开放标准协议：它让大模型在运行时发现并调用外部工具，从单纯的文本生成扩展到可执行动作——读写文件、查询业务系统、检索知识库、触发自定义业务逻辑等。灵渠把这套能力纳入平台治理：对外聚合多个 MCP 工具服务器，对内让每一次工具调用与普通查询请求一样，依次流经路由、缓存检查点、安全护栏三类中间件。
本节面向部署、运维与集成灵渠平台的内部管理员，讲清三件事：MCP 是什么、灵渠作为 MCP 网关的双重定位、以及把工具调用纳入统一治理带来的价值。
本节定位。 MCP 网关是灵渠可编程能力在"工具侧"的延伸——它复用同一条中间件管道与同一套额度、计量、安全口径，而非另起一套治理。工具调用的治理细节与扩展点接入，须与 中间件管道与扩展点 SDK 一致；本节侧重 MCP 协议层与工具聚合，治理管道本身仍以
/middleware-pipeline为权威。
1. MCP 协议简述
MCP 把"模型能用哪些工具、怎么调用工具"标准化为一套统一的发现与调用约定。其核心是两个动作：
| 动作 | 含义 |
|---|---|
| 工具发现（list） | 客户端向工具服务器询问"你提供哪些工具"，拿到工具名、描述与参数结构清单 |
| 工具调用（call） | 客户端按某个工具的参数结构发起一次调用，工具服务器执行后返回结构化结果 |
模型本身并不直接执行工具——它只在响应中建议调用某个工具（给出工具名与参数）。是否真的执行、按什么次序执行、要不要人工确认，由承载这段对话的应用决定。这条"建议与执行分离"的边界，是 MCP 安全可控的基础，灵渠在网关层完整保留并强化了它。
2. 灵渠的双重定位：既是 MCP 客户端，也是 MCP 服务器
灵渠在 MCP 协议链路上同时扮演两个角色，对外把"接入工具"与"输出工具"统一到一个入口：
| 角色 | 面向 | 职责 |
|---|---|---|
| MCP 客户端 | 上游工具服务器 | 接入外部 MCP 工具服务器（文件操作、检索、业务系统等），发现并代理其工具 |
| MCP 服务器 | 下游 MCP 宿主 | 把已接入的全部工具聚合为单一 MCP 端点，对外暴露给支持 MCP 的宿主应用 |
这一双重定位带来一种"工具聚合"模式：灵渠接入若干个 MCP 工具服务器，把它们的工具汇成一份统一注册表，再通过一个 MCP 端点对外提供；下游宿主只需连接灵渠一处，即可使用全部聚合工具，无需逐一对接每个工具服务器。
灵渠作为 MCP 客户端接入的每个工具服务器，在平台内称为一个 MCP 连接（见 接入 MCP 服务器）；它作为 MCP 服务器对外暴露时，按调用方所持密钥过滤可见工具，不同密钥看到的工具集可不同（见 工具执行与治理）。
3. 工具调用同样经中间件管道治理
灵渠的核心理念是"每一次请求都被治理"。工具调用并不例外——它在网关内与普通查询请求共用同一条有序中间件管道：路由中间件研判该把工具调用代理给哪个上游工具服务器并做健康检查与故障转移；缓存检查点判定结果是否可短路复用；安全护栏对工具参数与返回结果施加访问控制、敏感信息脱敏与应拒答复核。
下图勾勒一次"模型建议调用工具 → 应用确认 → 灵渠执行 → 续接对话"的典型时序，工具执行环节即落在中间件管道中：
能力边界一致。 与三类内建中间件相同，MCP 网关只在控制面 / 治理面对工具调用施加处置——路由代理、健康检查、缓存判定、参数校验、结果脱敏与拦截——并不替代工具服务器执行业务逻辑，也不对工具返回内容做实质性的生成或改写。工具的实际执行由所选定的上游工具服务器完成。这条边界与 中间件管道 的统一边界声明完全一致。
4. 统一治理的价值
把工具调用纳入网关，价值不在于"能调工具"本身（那是 MCP 协议给的），而在于工具调用与普通查询共享同一套治理底座：
| 维度 | 统一治理带来的效果 |
|---|---|
| 单一入口 | 下游宿主只对接灵渠一处，即可使用全部聚合工具，新增 / 下线工具服务器对宿主透明 |
| 访问控制 | 按密钥（子账户）粒度过滤可见与可执行的工具，遵循最小权限；不同业务线看到的工具集可不同 |
| 安全护栏 | 工具参数与返回结果经入站 / 出站护栏，注入防护、敏感信息脱敏、应拒答复核与普通查询同一基线 |
| 健康与韧性 | 平台周期性探测各工具服务器健康状态，瞬时故障自动重试与重连，工具不可用对宿主可见、可恢复 |
| 计量统一 | 工具调用与查询用量归口同一份用量底座，逐条可追溯，跨页面数字对得上 |
| 建议与执行分离 | 平台默认不自动执行模型建议的工具调用，执行需经应用显式发起，保留人工把关空间 |
与普通查询的口径一致。 工具调用的逐条记录、健康状态、护栏处置结果，都进入与查询请求相同的监控与用量视图。运营人员无需在两套口径间切换，即可对"查询 + 工具"全链路统一观察。
5. 本节导航
| 子页 | 内容 |
|---|---|
| 接入 MCP 服务器 | 三类连接方式、连接配置字段、工具准入范围、连接状态机与健康探测、连通性韧性 |
| 工具执行与治理 | 建议与执行分离的执行流程、三级工具过滤规则、按密钥会话与凭据生命周期 |
相关链接
- 中间件管道与扩展点 SDK：三类治理中间件、执行位次、短路语义——工具调用治理复用同一条管道。
- 快速开始：部署、初始化、跑通首个查询请求的最短路径。
- API 参考：数据平面与控制平面的通用接口约定与端点契约。