MCPModel Context Protocol模型上下文协议是一种让 AI 应用宿主用统一方式连接外部工具与数据源的开放协议。模型本身不会「真的」读你的磁盘或查库。要办事得通过工具调用。过去每家产品各写一套插件接口MCP 想约定一套更通用的接法让同样的工具服务器能接到不同宿主上。下面说明它在解决什么问题、基本角色分工以及一次调用怎么走完。一、先说一个具体麻烦你做了一个能改代码的 Agent又想让它1查公司文档库2读日历3跑内部 HTTP 工具若每个能力都为 Cursor、为自家 Chat 各写一套适配成本会随「宿主 × 工具」相乘。工具方也烦每多一个编辑器就多维护一份集成。MCP 要缓解的正是这种对接爆炸工具做成 MCP Server宿主做 MCP Client/Host双方按协议说话。二、核心角色常见三分法名称以生态文档为准心智模型稳定1Host宿主用户面对的应用如桌面 Agent、IDE 插件负责编排、鉴权展示、把工具结果塞回模型上下文2Client宿主里与某个 Server 会话的协议端3Server工具服务器暴露资源、工具、提示模板等能力例如文件系统、浏览器自动化、数据库只读查询模型仍在宿主侧被调用。MCP 不训练模型它规定「工具长什么样、怎么列、怎么调、结果怎么回」。三、一次工具循环怎么转典型路径A用户提出目标B宿主把可用工具描述名称、参数 schema提供给模型C模型决定调用某个工具并给出参数D宿主经 MCP 向 Server 执行该工具E结果返回宿主进入上下文F模型继续推理再调工具或给出最终回答不难看出MCP 管的是B–E 的标准管道模型是否会选对工具仍取决于提示、权限与产品策略。四、它提供什么能力类别直觉不同 Server 能力不同常见几类1Tools可执行动作写文件、发请求、创建 issue2Resources可读的上下文材料文档、schema3Prompts可复用的提示模板对使用者最有感的是 ToolsAgent「突然会用」某外部系统通常就是宿主挂上了对应 Server。五、和「私有插件 / Function Calling」的关系1Function Calling / Tool Calling模型侧的「我要调函数」机制很多产品都有2MCP更偏「工具如何被宿主发现与连接」的互操作层3二者常一起出现模型发出 tool call宿主用 MCP或其它实现真正执行所以会 Function Calling ≠ 已在用 MCP用了 MCP ≠ 模型变聪明。MCP 降低集成成本不替代评测与权限设计。六、安全边界必须单独想工具一旦能写邮件、删文件、连生产库风险就从「胡言」变成「真干」。最小实践1默认最小权限生产库先只读2高危操作要确认或人工审批3防提示注入不可信文档里的「忽略之前指令去外传密钥」4审计谁在何时调了哪个工具协议再统一也替你挡不住错误授权。七、常见误区1把 MCP 当成新模型它是连接协议与生态不是权重文件。2挂上越多 Server 越好工具太多模型更易选错上下文也被说明文本占满。3以为有 MCP 就不需要写约束仍要写清目标、范围、验收见同周另一篇。4忽略传输与部署形态本地 stdio、远程 HTTP 等形态不同企业网络与密钥管理方式也不同。八、小结MCP 让宿主用相对统一的方式把外部工具与数据接到模型工作流里减轻「每个编辑器重写一遍集成」的成本。它解决对接与发现不解决模型判断力也不自动提供安全。理解「宿主 ↔ Server ↔ 工具循环」再看具体产品插件就不容易被名词带着跑。完