MCP 基础设施是公开并运行 Model Context Protocol 能力所需的全部组件，包括客户端、传输层、服务器、工具、授权、策略、凭据、后端执行、状态和遥测。MCP 服务器只是其中一个组件，并不等同于完整的生产系统。
演示可以在 tools/list 和 tools/call 成功后结束。生产系统还必须回答：谁发起了调用、调用方能访问什么、写入是否可能重复，以及运维人员如何还原操作造成的影响。
MCP 标准化了什么
MCP 定义了一套 JSON-RPC 协议，让客户端与服务器协商能力并交换消息。服务器可以提供：
- 可由模型选择并调用的工具；
- 可由客户端读取或订阅的资源；
- 可由客户端展示给用户或模型的可复用提示词。
MCP 工具规范定义了通过 tools/list 发现工具、通过 tools/call 调用工具、输入和可选输出 schema、结构化内容，以及工具列表变更通知。
协议负责传递这些契约，但不会判断某项工具对当前租户来说是否安全、实用或已获授权。
协议周围的基础设施
flowchart LR
C[MCP client] --> T[stdio or Streamable HTTP]
T --> S[MCP server]
S --> A[Authentication and policy]
A --> X[Credential and execution layer]
X --> B[Backend APIs and data]
S --> R[Session and operation state]
S --> O[Logs, traces, and evaluations]
X --> O
B --> O
每条边界都有独立职责。
客户端与传输层
客户端决定向模型开放哪些服务器能力，以及由用户如何审批调用。本地服务器通常使用 stdio，远程服务器则使用 Streamable HTTP。MCP 传输规范还要求 HTTP 服务器校验 Origin header，以帮助防范 DNS rebinding 攻击。
传输安全只能保护连接，不能对数据库行或云资源进行授权。
服务器与工具注册表
服务器实现 MCP 生命周期消息，并发布工具、资源或提示词。工具注册表包含名称、描述、schema 和 annotation。除非服务器本身可信，否则客户端必须将工具 annotation 视为不受信任的数据。
工具定义应贴近任务，而不是内部端点名称。MCP 工具设计指南介绍了如何减少相互重叠的选项，并返回模型能够使用的结果。
身份验证与策略
身份验证负责识别调用方或其代表的用户，策略则决定该身份能访问哪些工具、资源、租户和操作。对于 HTTP 传输，MCP 授权规范定义了一套基于 OAuth 的流程，包含受保护资源发现、授权服务器元数据、资源指示符、bearer token、PKCE 和 audience 校验。
后端必须继续执行授权检查。即使网关隐藏了 delete_project，底层 API 仍应拒绝未授权的删除操作。
凭据与执行层
MCP 服务器可能需要单独的 token 来调用上游 API。当前授权规范明确禁止将客户端的 MCP access token 直接传递给上游服务。服务器应换取或取得一项专门用于该后端的独立凭据。
不要在工具参数和结果中放置这些凭据。模型需要的是操作结果，而不是获取结果时使用的密钥。MCP 密钥安全指南详细追踪了凭据的完整路径。
后端、状态与恢复
后端负责业务授权、数据完整性和外部影响。会话状态可以记录当前启用的服务器连接，操作状态则记录一项具体写入是已经开始、完成、失败，还是需要核对结果。
不要将聊天记录作为唯一的操作账本。工具结果摘要不足以判断一次超时的付款或部署是否应该重试。
遥测与评估
一条追踪记录应串联用户请求、模型选择、工具调用、策略决策、后端请求和最终影响。记录稳定的租户、用户、agent、会话、工具调用和操作 ID，排除 token、凭据和敏感 payload。
评估套件应覆盖工具选择冲突、无效输入、禁止访问的资源、审批路径、重试和响应中断。即使某项工具单独使用时正常，当二十个类似工具同时可见时仍可能失败。
检查一条完整的工具调用路径
选择影响范围最广的 MCP 工具，越过处理程序继续追踪身份、策略、凭据、后端状态和遥测。如果任何步骤依赖提示词指令或人工阅读日志，应将其标为缺失的基础设施。
下方的提示词会在不调用工具的情况下执行这项追踪。