MCP （Model Context Protocol，模型上下文协议）由 Anthropic 在 2024 年开源，它是一套让 AI 应用连接外部数据、工具和工作流的开放协议。它统一了能力如何被发现、描述和调用，使文件系统、数据库、代码仓库与企业应用可以通过相对一致的方式被 Agent 使用。
让大模型总结一段已经放进对话框的文字，主要依赖模型自身的理解与生成能力。但下面这个任务不一样：
找到上季度销售数据，关联客户等级，分析销售变化，再把结论整理成经营周报。
要完成它，Agent 至少需要知道：
过去，开发者往往为每个 AI 应用和每个外部系统单独开发连接。应用一多、工具一多，适配代码、认证方式和维护成本也会随之增长。
MCP 的作用，是在 AI 应用与能力提供方之间增加一层共同协议。外部系统按照协议暴露能力，兼容的 AI 应用按照协议建立连接，从而减少重复适配。
这也是为什么 MCP 常被类比为“AI 应用的 USB-C”。USB-C 规定怎样连接设备，却不规定连接的是硬盘、显示器还是键盘；MCP 规定怎样连接能力，却不替企业定义具体业务逻辑。
一次典型的 MCP 调用包含三个角色。
| 角色 | 主要职责 | 常见形态 |
|---|---|---|
| Host（宿主应用） | 承载用户、模型、对话、权限策略和多个连接 | 桌面 AI 应用、IDE、企业 Agent 平台 |
| Client（客户端） | 与某个 MCP Server 建立会话，发现能力并发起调用 | Host 内部的 MCP 连接组件 |
| Server（服务器） | 把外部数据、工具或工作流以协议规定的方式暴露出来 | 文件、数据库、GitHub、知识库、业务系统的 MCP Server |
可以把调用过程理解为：
用户提出任务 → Host 理解任务并选择可用能力 → MCP Client 向 Server 发起请求 → Server 调用真实系统 → 结果返回 Host → 模型组织答案或决定下一步
例如，用户在 AI 应用中问“这个代码仓库最近一周有哪些高风险改动”。模型先判断需要读取仓库信息，再通过 MCP Client 调用代码仓库 Server。Server 返回变更记录后，模型才能继续分析。
模型仍然负责理解和判断，MCP 负责把判断连接到外部能力。
在 MCP 中，Server 可以向 Host 暴露不同类型的能力。常见概念包括：
| 能力 | 解决什么问题 | 示例 |
|---|---|---|
| Tools | 让模型执行查询或动作 | 查询数据库、创建工单、写入文件 |
| Resources | 向应用提供可读取的上下文 | 文件内容、数据库 Schema、项目文档 |
| Prompts | 提供可复用的交互入口或提示模板 | 生成周报、审查代码 |
不同 Host 对这些能力的支持范围可能不同，具体应以当前客户端和 Server 文档为准。
协议统一了能力交换方式，却不会自动生成高质量工具描述。工具名称含糊、参数边界不清或返回值缺少说明，模型仍然可能选错工具。因此，MCP Server 的设计质量不仅取决于接口能否调用，也取决于能力描述是否准确、输入输出是否稳定、失败信息是否可理解。
以“查询某地区明天的天气”为例，一次调用通常经历以下步骤：
如果任务包含多个系统，Agent 可以连续调用多个 Server。例如先读取订单数据，再查询客户信息，最后调用文档工具生成报告。MCP 提供的是可组合的连接基础，任务顺序和验收标准仍需要由 Agent 工作流或 Skill 规定。
Function Calling 是模型或模型 API 表达“我要调用这个函数”的机制，MCP 是应用与能力提供方之间的协议。两者经常一起工作，但关注的层次不同。
| 对比维度 | Function Calling | MCP |
|---|---|---|
| 核心问题 | 模型怎样表达“我要调用某个函数” | AI 应用怎样发现、连接和调用外部能力 |
| 能力定义 | 通常由应用直接提供给模型 | 通常由 MCP Server 按协议暴露 |
| 连接与会话 | 由应用自行实现 | 协议包含连接、初始化和能力协商机制 |
| 复用范围 | 容易与具体应用实现绑定 | 同一 Server 可被多个兼容 Host 复用 |
| 能力范围 | 以函数或工具调用为主 | 可包含 Tools、Resources、Prompts 等 |
一种常见组合是：模型通过 Function Calling 表达工具选择和参数，Host 再通过 MCP 把调用交给外部 Server。具体产品可能采用不同实现，因此不宜把二者描述成简单的替代关系。
至少需要检查以下六点：
企业还应审查 MCP Server 的来源、依赖和版本。扩展能力越接近核心数据和业务动作，安全评估就越不能只停留在提示词层面。
MCP 更适合以下情况：
如果只是单个应用调用一个稳定 API，也没有跨应用复用需求，直接使用应用内置工具或 Function Calling 可能更简单。选择 MCP 应来自真实的连接与复用需求，而不是因为它是热门名词。
对于企业数据分析，可以把三层能力分开理解：
企业语义层：定义“数据是什么意思、指标怎样计算” → MCP：把受治理的问数能力连接给外部 Agent → Skill：规定拿到数据后怎样分析、核验和交付
例如，YiAsk MCP 可以把亿问 Data Agent 的问数能力提供给兼容的外部 Agent。MCP 负责连接，亿问的语义模型和查询链路负责解释企业数据，宿主 Agent 或 Skill 再继续完成报告、代码或其他任务。
这也说明：连接能力、数据可信和任务方法是三件不同的事。把它们分层，才能知道问题应该在哪一层解决。
不是。MCP 是一套协议。具体的 Host、Client、Server 和能力目录由不同产品实现。
通常仍然需要。MCP Server 往往会在后台调用数据库、API、文件系统或 SaaS 服务。MCP 统一的是 Agent 与 Server 的交互方式，不会消除底层系统接口。
不一定。Function Calling 关注模型如何选择函数，MCP 关注应用如何发现并连接外部能力，两者可以协同工作。
不应该。需要连接外部系统时使用 MCP；需要沉淀一类任务的流程、规则和验收标准时使用 Skill。复杂任务通常会同时使用两者。
因为连接并未定义指标、时间、身份、退款和权限口径。企业还需要语义建模、数据治理和可追溯执行链路。
本文解释的是 MCP 的通用工作方式，不代表所有 Host 都支持相同传输、认证和协议能力。MCP 仍在演进，生产环境应以所用 Host、SDK 和 Server 的当前官方文档为准。
涉及企业数据时，还应单独确认数据来源、用户身份、空间范围、行列权限、审计记录和写操作审批。协议兼容不能替代这些治理工作。