什么是 MCP？
MCP（Model Context Protocol，模型上下文协议）是一种开放、版本化协议，使 AI Host 能通过 Client 以自包含 JSON-RPC Request 发现和调用 Server 暴露的边界化能力。
快速了解
| 全称 | 模型上下文协议 |
|---|---|
| 创建时间 | 2024 年 11 月由 Anthropic 发布 |
| 规范文档 | 官方规范 |
工作原理
角色与协议范围
Host 是面向用户的 AI Application 与策略边界，为每段直接 Server 关系创建 MCP Client，集成模型、组装 Context 并处理 Consent；Client 实现协议交换；Server 暴露边界明确的能力。MCP 不定义模型 Reasoning Loop、Memory、Marketplace、Billing、业务授权或后端 Source of Truth。产品可以打包多个角色，但职责仍应分开。
当前无状态核心
在 2026-07-28 版本中，不再存在 initialize / initialized Handshake 或 Protocol-level Session。每个 Request 都在 _meta 中携带 io.modelcontextprotocol/protocolVersion 与 io.modelcontextprotocol/clientCapabilities，Client 与 Server Identity Metadata 均为自述。Server 实现 server/discover，Client 可以先发现版本和能力，也可直接请求并处理版本错误；应用状态使用显式、受限 Handle。
Core Feature 与 Extension
Server 可暴露 Model-controlled Tool、Application-controlled Resource 与 User-selected Prompt；Client 可支持用于补充用户输入的 Elicitation。Utility 覆盖 Progress、Cancellation、Error、Pagination、Caching 与 Subscription。Tasks、Skills over MCP、MCP Apps 等可选 Extension 使用带命名空间 Identifier、独立规范、双端显式支持与降级路径；支持 Core 不代表支持任一扩展。
Transport 与兼容路径
当前标准 Binding 是 Host 启动本地进程时使用的 stdio，以及远程 Endpoint 使用的 Streamable HTTP。Modern Streamable HTTP 只有一个 POST Endpoint，Response 可为 JSON 或 Request-scoped SSE；旧独立 HTTP+SSE 已弃用。2025-11-25 及更早版本采用 Stateful Lifecycle，应作为隔离的 Legacy 路径处理。固定协议与 SDK 版本，联合测试两端，禁止静默混用协议时代。
信任、授权与证据
协议合法只能证明 Message Shape，不能证明身份、事实、必要性或权限。Host 应校验 Server Provenance、为能力分配 Namespace、约束 Context、展示高影响 Argument，并把 Output 视为不可信；Server 按需认证调用方，执行 Tenant/Object Policy、领域校验、Result Limit 与幂等副作用。远程 OAuth、本地进程 Sandbox、取消、可观测性、删除和事故恢复仍是部署责任。
主要特点
- 三个逻辑角色：Host 管理应用策略，Client 管理协议关系，Server 暴露能力
- 当前逐请求无状态：每个 Request 自带版本、Client Capability 与相关 Identity Metadata
- 类型化能力面：Tool、Resource、Prompt、Elicitation、Utility 与 Extension 使用不同契约
- 两种标准 Transport：本地子进程使用 stdio，远程 Endpoint 使用 Streamable HTTP
- 独立可选扩展：双方按 Identifier 显式 Opt-in，并保留 Core Fallback 或明确错误
- 外部信任控制：认证、授权、Consent、Sandbox、Idempotency 与 Audit 仍由应用负责
常见用途
- 通过 stdio 把 IDE 连接到经过审核的本地代码仓库与测试能力
- 通过受限远程 Tool 暴露具备 Tenant 感知的 SaaS 或内部 API
- 以 URI-addressed Resource 提供经过授权的文档或业务记录
- 向兼容 Host 分发用户选择的 Prompt Template 或已验证 Skill
- 通过 Tasks 运行带审批、恢复与 Effect Tracking 的长任务
示例
Loading code...常见问题
MCP 与 Function Calling 或普通 API 有什么区别？
Function Calling 通常是模型供应商让模型提出结构化调用的格式，API 则直接暴露后端操作。MCP 在 Host 与 Server 之间增加标准化角色、Capability Discovery、Transport、Result、Version 与可选 Extension。Host 可以把 MCP Tool 转为某家模型的 Function Calling 格式，但后端仍需独立授权和业务规则。
MCP 2026-07-28 还使用 initialize 与 Session 吗？
不使用。当前 Core 是无状态协议：每个 Request 携带协议版本和相关 Client Capability，`server/discover` 可用于可选的前置发现。Initialize、`notifications/initialized` 与 Protocol-level Session ID 属于 Legacy 版本；业务流程仍可通过显式、受限 Handle 保存状态。
哪些 MCP 能力属于 Core，哪些属于 Extension？
Core 定义角色、JSON-RPC Request Model、Tool、Resource、Prompt、Elicitation、Transport 与 Utility。Tasks、Skills over MCP、MCP Apps 和补充授权机制属于拥有独立 Identifier 与支持矩阵的可选 Extension。支持 MCP Core 不代表支持任何扩展。
MCP 部署应选择 stdio 还是 Streamable HTTP？
Host 启动并隔离的本地进程适合 stdio；需要 HTTPS、可选 OAuth、水平扩展和 Request-scoped JSON/SSE Response 的远程服务适合 Streamable HTTP。独立 HTTP+SSE 已弃用。应依据目标 Host 的真实支持选择，并测试取消、重试、Limit 与 Credential。
MCP 会让 Tool 与 Resource 自动变得安全或已授权吗？
不会。Schema 与 Metadata 只描述契约，不能认证调用方、授权对象、证明内容真实或让副作用幂等。Host 负责 Provenance、Context、Consent 与面向模型的 Policy；Server 则要在每个 Request 上执行 Identity、Tenant/Object Access、Domain Validation、Effect Safety 与 Output Limit。