Anthropic 对 MCP（Model Context Protocol）的定义是：
“A new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments.”
其定位与愿景也十分明确：
• 定位：一个协作式开源项目和生态系统。
• 目标：帮助前沿模型产生更好、更相关的回答，让 AI 在不同工具和数据集之间移动时能保持上下文，最终实现可感知上下文的 AI（context-aware AI）。
• 理念：让创新变得可访问、透明、植根于协作——像 Block 的 CTO 所说，把 AI 连接到真实世界应用，将人从机械性工作中解放出来，专心创造。
很多人会自然联想到 Function Calling，但二者完全不在一个维度。Function Calling 是 LLM 调用外部工具的一种具体机制，而 MCP 是 Agent 与数据系统之间的标准通信协议及实现体系。MCP 中的工具调用当然可以基于 Function Calling 来完成，但它在系统层面做了标准化抽象。因此，MCP 是构建在 Function Calling 之上的系统级协议。
一、为什么需要 MCP？——从 Function Calling 的痛点切入（以模型调用为例）
我们来看一个典型的 Function Calling 流程：
- 注入工具 Schema：开发者将工具定义（JSON Schema）放入 API 请求的 tools 参数。
- 模型返回调用：模型输出 tool_calls，包含函数名和参数。
- 外部执行：开发者手动解析，并调用本地或远程函数。
- 结果回传：将结果包装为 role=tool 的消息，再次请求模型。
这种模式的突出问题：
• 厂商绑定：工具 Schema 与 LLM 提供商强绑定。同样是 get_weather，OpenAI 的格式和 Anthropic 的格式在结构和字段命名上完全不同（例如 OpenAI 使用 type 和 parameters，而 Anthropic 使用 input_schema）。
• 无执行标准：工具实际怎么调用，完全由开发者硬编码，没有标准化的接口。
• 功能简陋：一次调用只返回一个结果，不支持进度、取消或流式输出。
当工具越来越多、数据源五花八门时，这种“每次临时贴 Schema + 手工调度”的方式会迅速失控。
二、MCP 的 Tools 如何标准化工具调用？
MCP 提供了一套标准的工具调用流程，将“描述”与“执行”解耦：
- 工具发现（前置）
MCP Client 与 Server 握手时，通过 tools/list 获取完整的工具列表和 JSON Schema。工具描述不再随请求发送，而是独立存储在 Server 端。 - 模型决策
Host（如 Claude Desktop）将 MCP 工具与本地功能合并，通过 LLM 的 Function Calling 机制让模型决定调用哪个工具。 - Host 转换为 MCP 调用
模型选定工具后，Host 不再直接调用函数，而是通过 MCP Client 发送标准 JSON-RPC 请求，包含 method: tools/call 以及对应的参数。 - Server 执行并返回
MCP Server 处理实际逻辑并以 JSON-RPC 格式返回结果内容。 - 结果回传 LLM
Host 将结果转为模型能理解的 tool 消息，继续对话。
你可能问：既然各厂商的 Schema 不同，MCP 不还是需要一个适配层吗？
没错，适配层仍然需要，但 MCP 把问题大大简化了。对比一下普通 Function Calling 与 MCP：
【工具描述格式】
普通：随厂商而异的 JSON Schema 方言。
MCP：统一 Tool 类型，基于标准 JSON Schema，字段固定。
【工具存储】
普通：随请求临时发送。
MCP：独立 Server 存储，由 tools/list 获取。
【工具调用协议】
普通：无标准，开发者自行实现 HTTP/gRPC/本地调用。
MCP：标准 JSON-RPC 方法 tools/call。
【工具执行环境】
普通：与 Agent 代码耦合。
MCP：独立进程、跨语言、跨机器运行。
【高级特性】
普通：无（或厂商专有）。
MCP：进度通知、取消、流式返回等（协议原生支持）。
没有 MCP 时，适配层不仅要处理格式转换，还得操心：工具在哪里执行？如何发现新工具？调用时的网络、超时、重试、认证怎么做？
有了 MCP，所有“外围事务”都被标准化。适配层只需专注格式转换，其余均由协议保证。这个转换层完全可以做成一个通用库，一劳永逸。
三、远不止 Tools：Resources 和 Prompts 带来的能力跃升
MCP 的核心不只是标准化了函数调用，它定义了三种能力基元，将 AI 与外界的交互从“单一动作”扩展到“知识获取、流程复用、动态协商”。
- Resources（资源）——为模型提供标准化的“传感器”
Function Calling 要读取数据必须单独写一个函数，且每次调用都要计为一次 action，也无法主动推送变更。MCP 的 Resources 将数据源抽象为可发现的 URI：
• 资源发现：通过 resources/list 浏览所有可用资源，支持 URI 模板动态匹配。
• 只读语义：协议保证资源读取无副作用，Host 可安全地自动拉取，无需用户每次确认。
• 实时订阅：Client 可订阅资源，资源变化时 Server 主动推送通知，模型被动感知数据更新。
• 多内容类型：支持文本和二进制，省去编码协商。
这相当于为 AI 装上了一套标准化的传感器总线，能动态发现并订阅外部世界的变化。 - Prompts（提示模板）——可复用的“认知流程”固件
如果你想重复使用一套复杂的提示流程，传统做法只能每次手动拷贝。MCP 的 Prompts 让提示模板成为可发现、可参数化、可管理的资源：
• 模板发现：prompts/list 列出所有可用的思维框架。
• 动态填充：通过 prompts/get 传入参数，Server 返回填好的完整提示。
• 多角色支持：模板能返回 user、assistant 等混合角色消息，引导复杂交互。
• 版本管理：Server 更新模板后，Client 可收到变更通知，提示升级无需改代码。
这好比为模型预置了可插拔的“思考程序”，实现了认知流程的复用与迭代。
【能力全景对比】
• 能力范围：普通 Function Calling 仅可执行函数；MCP 可执行操作 + 只读数据 + 提示模板。
• 发现机制：普通无发现机制，需预先注册；MCP 动态 list 查询，支持变更通知。
• 传输协议：普通为厂商自有格式；MCP 为标准 JSON-RPC over stdio / HTTP。
• 安全模型：普通靠 Token 校验；MCP 支持 OAuth 2.1、人在回路、细粒度授权。
• 资源管理：普通无；MCP 支持订阅/推送、URI 模板、内容协商。
• 长时间任务：普通不支持；MCP 支持进度通知与取消操作。
• 提示复用：普通无；MCP 支持参数化模板、多角色输出、动态生成。
四、MCP 的核心角色：Host、Client、Server
明确 Host、Client 和 Server 的分工，是理解 MCP 如何解耦 Agent 与工具的关键。
【Host】
• 职责：AI 应用本身，负责接收用户输入、维护 LLM 对话、整合上下文。它通过 MCP Client 调用能力，不直接访问 Server。
• 典型形态：Claude Desktop、IDE 插件、自研 Agent 等。
【Client】
• 职责：MCP 协议的代理层，作为 Host 与 Server 之间的翻译器。负责建立连接、发送请求、处理响应并返回给 Host。
• 典型形态：各种编程语言的 MCP SDK。
【Server】
• 职责：独立进程，对外暴露 Tools、Resources、Prompts 等具体能力。Server 只遵循协议执行请求，不关心是谁在调用。
• 典型形态：本地文件系统 Server、数据库 Server、云端函数计算 Server。
一次典型交互的生命周期：
连接建立 -> 能力协商（获取可用列表） -> 模型决策（LLM 决定调用哪个工具） -> 能力调用（通过 Client 发送标准请求） -> 结果回传 -> 资源订阅（可选）。
这种“决策与执行分离”让工具和数据的提供方可以独立演进，真正做到了“一次编写，处处使用”。
五、MCP 的安全模型：从“裸奔调用”到企业级护城河
MCP 从协议层就内建了一整套安全机制：
- 传输层安全：使用 HTTP 传输时强制建议 HTTPS 加密；本地 stdio 传输由操作系统进程隔离保障。
- 认证体系：推荐使用 OAuth 2.1 机制，基于 Token 鉴权，且 Token 可以限定读写等作用域。
- 细粒度授权与“人在回路”：
• 工具白名单：Host 可过滤工具列表，只允许模型调用特定子集。
• 读写分离：Resources 协议保证只读，Tools 可能有写操作，可差异化授权。
• 人在回路：高风险操作（如删除、发邮件）在执行前可弹出确认框让人类审批。
• 资源控制：限制特定资源只对特定用户可见。 - 审计与可观测性：标准通道可自然记录调用者、时间、参数和结果，方便接入企业日志和合规系统。
- 云端集成：结合 API 网关、RAM 角色和 KMS 密钥管理，实现最小权限原则，避免硬编码。
六、结语：MCP 的本质是 AI 与 数据系统交互的“USB 总线”
MCP 并不试图统一所有 LLM 的输入/输出格式。它做的是：统一工具、数据和提示的“描述方式”与“访问接口”，让 AI 可以像计算机外设一样，自由发现并安全使用各种能力和数据。
在 Tools 能力中，Server-Client 架构让 Host 彻底从工具发现、执行、认证和传输等繁琐事务中解放出来，还带来了进度通知、取消和流式返回等高级特性。
更关键的是，Resources 为模型装上了可发现、可订阅的“传感器”；Prompts 为模型预置了可复用、可迭代的“思考程序”。
如果说 MCP 是一座大厦，Function Calling 仅仅是这座大厦某根支柱的地基。二者在抽象层次和系统能力上有着本质区别。
【典型面试题】
问：什么是MCP？
答：MCP 是 Anthropic 在 2024 年底推出的 Agent 与数据系统之间的标准通信协议及实现体系协议。MCP中有三个核心角色，分别是Host、Client、Server，三个角色完成了Agent与数据系统的解耦。MCP有三大能力Tools 用于执行有副作用的操作，Resources 是只读数据，Prompts 是提示词模板，底层用 JSON-RPC 2.0 通信。其中Tools能力主要解决的是「模型接工具太碎片化」的问题。在 MCP 出现之前，每接一个新工具都要单独写集成代码、处理认证、适配格式，而且这套代码和具体模型强绑定，换个模型就得重写，非常繁琐。MCP 的思路是把这件事标准化：工具提供方按协议实现一个 Server，任何支持 MCP 的 AI 客户端就能直接接进来，一次实现到处复用。
问：MCP有哪几部分组成？
答：从角色层看有 Host（AI应用）、Client（通信模块）和 Server（能力提供方）。从能力层看有 Tools（有副作用的操作）、Resources（只读数据）和 Prompts（提示词模板）。从协议层看，底层消息格式用 JSON-RPC 2.0，支持 stdio（本地）和 Streamable HTTP（远程）两种传输方式。
问：MCP和Function Calling的区别？
答：Function Calling 是一种模型输出层的约定，解决“如何调用”的问题。MCP 是工具生态系统协议，解决“如何让调用可持续、可管理、可规模化”的问题。MCP 底层虽然用 Function Calling 触发调用，但它在此之上增加了一套完整的工具管理框架，接管了工具的发现、描述、传输和安全等工程关注点。两者不在同一抽象层次。
问：MCP和Skill的区别？
答：MCP 提供基础能力原语（读写工具、数据源、提示模板），侧重于工程上“如何连接到数据系统”。Skill 封装的是特定领域的业务知识和工作流 SOP，直接绑定好了用到的工具和资源，降低模型试错概率。MCP 管能力总线，成功标准是“连得上、调得通”；Skill 管任务质量，成功标准是“少产生幻觉、把事情干好”。
问：MCP 如何保证安全性？
答：MCP 在多层内建安全：传输层走 HTTPS 或隔离的进程通信；认证层推荐 OAuth 2.1 鉴权和限制 Token Scope；授权层支持 Host 设置工具白名单、读写分离控制；执行层支持“人在回路”的高风险拦截审批；日志层支持所有调用记录标准化，方便企业审计合规。
问：MCP 与 A2A 协议有什么区别和联系？
答：MCP 解决 AI 与外部工具、数据系统之间的连接，是“AI 的外设总线”，场景是单 Agent 读写文件或查数据库。A2A（Agent-to-Agent）解决多个 Agent 之间的任务协商与协同工作，是“跨 Agent 的社交语言”，场景是不同分工的 Agent 互相传递需求和结果。两者互补：MCP 管内部能力接入，A2A 管外部 Agent 协同。
