一句话定义：MCP（Model Context Protocol，模型上下文协议）是一套开放标准，规定了「大模型如何统一地连接外部工具、数据源和系统」。
它到底解决什么问题
假设你想让 AI 助手查公司数据库。过去得为这个模型写一套对接代码；换一个模型，重写；再接一个日历，再写一套。三个模型 × 十个工具 = 三十份定制胶水代码，这就是常说的 M×N 问题。
MCP 的做法是把接口标准化：工具提供方按协议实现一个 MCP Server，模型应用这边实现一个 MCP Client，两边就能连上。于是 M×N 变成 M+N——工具写一次，所有支持 MCP 的客户端都能用。
这就像 USB-C：以前每个设备一条专属线，出门得带一包；接口统一后，一根线搞定大半。也像普通话：大家都说普通话，任意两个人对话就不用各配一个翻译。
具体长什么样
一个宿主应用（比如 IDE、桌面助手）里跑 MCP Client，每个 Client 连一个 MCP Server。Server 通常暴露三类东西：
- Tools（工具）：可执行的动作，比如发邮件、建工单；
- Resources（资源）：可读取的上下文，比如某个文件、某张表的内容；
- Prompts（提示模板）：预设好的指令模板。
传输方式常见两类：本地进程走标准输入输出，远程服务走 HTTP 类传输。具体规范细节以官方页面为准。
和相邻概念的区别
| 概念 | 关注点 | 与 MCP 的关系 |
|---|---|---|
| Function Calling（函数调用） | 模型「决定调用哪个函数、参数怎么填」 | 互补：MCP 管工具从哪来、怎么接上 |
| 传统 API/SDK 集成 | 一对一写适配代码 | MCP 想把这层适配标准化 |
| RAG（检索增强生成） | 把资料检索出来塞进上下文 | MCP 的 Resources 也能供数据，但 MCP 还能执行动作 |
| Agent 框架 | 编排多步任务的逻辑 | MCP 是连接层，框架可以在其上调用 MCP 工具 |
一句话：Function Calling 管「要不要调」，MCP 管「工具在哪、怎么连」。
对从业者和普通人的意义
对工具与数据提供商，写一次 MCP Server，等于同时接入所有支持该协议的客户端，触达面变大。对模型与客户端团队，不必再为每个第三方服务各写一套集成。对开发者，技术选型时可以优先看客户端与服务端对 MCP 的支持程度，减少被单一平台锁死。
对普通职场人，意义是助手从「聊天」走向「干活」：直接读你的日历、工单、文档，然后动手改。但要注意，MCP 主要定义「怎么连」，权限边界、审计与数据合规仍需具体产品落实——接入前先看清楚：谁能读、谁能写。