MCP 协议流

MCP 要按三层看：宿主应用 runtime、MCP client、MCP server。模型不会直接“连接 MCP server”。模型只提出意图或工具调用建议，宿主应用决定能不能连接、能不能调用、结果怎样回灌。

三层职责

宿主应用 runtime 负责用户、租户、权限、工具白名单、风险等级、审批和审计。它决定某个 server 是否可用，也决定某次调用是否允许发生。

MCP client 负责 transport、初始化、能力发现、请求发送、响应接收和错误标准化。它是协议适配层，不应该承载业务权限判断。

MCP server 负责暴露 tools、resources 或 prompts，并按协议返回结果。server 可以有自己的认证和本地校验，但不能替代宿主应用的全局治理。

基本时序

典型链路是：runtime 根据当前用户和策略选择可连接 server；client 通过 stdio 或 HTTP transport 建连；双方初始化并协商能力；runtime 把发现到的工具纳入当前可用工具集；模型在受限工具集中提出调用建议；runtime 校验参数、权限和风险；client 发起调用；server 返回结构化结果；runtime 标准化结果、写 trace，再决定回灌模型、继续执行或人工接管。

这条链路里最容易混淆的是 capability discovery 和授权。发现能力只说明 server 有什么工具，不说明当前用户能用什么工具。真正的工具可见性应该由宿主应用按用户、租户、任务和风险重新裁剪。

失败与排查

连接失败先查 transport、进程生命周期、环境变量和认证。能力发现失败先查协议版本、server 初始化和工具注册。调用失败先查 schema、参数补全、权限、超时和下游错误。结果回灌异常再查 envelope、trace id、错误分类和模型是否误读工具结果。

面试表达

可以这样答：MCP 解决工具接入标准化，不解决完整治理。我的设计里，runtime 先做身份、租户和策略判断，再让 MCP client 建连和发现能力。发现到的工具还要按当前会话裁剪，模型只能在裁剪后的工具集中提调用建议。真实执行仍由服务端做 schema 校验、权限判断、超时、审计和人工确认。