MCP：给模型接外部系统的统一插头

公司给 AI 接了工单、网盘和客户数据库。半年后准备换模型，技术团队却发现三套连接都按旧产品的私有格式重写过：参数名不同、鉴权不同、返回结果也不同。真正拖住更换的往往不是模型，而是这些接线工作。MCP试图解决的，就是应用与外部系统之间反复定制连接的问题。

先给答案

MCP 的全称是 Model Context Protocol，是一套让 AI 应用发现并使用外部数据、提示模板和工具的开放协议。也就是说，外部系统按共同规则说明“我有什么、怎么调用”，支持该协议的 AI 应用就能用相近方式连接，而不必为每一组产品从头约定接口。

谁在连接谁？

按官方规范，MCP 的基本角色有三类。Host 是承载模型和用户界面的 AI 应用，例如编辑器或桌面助手；Client 是 Host 内部负责某条 MCP 连接的组件；Server 则提供数据和能力。也就是说，一个 AI 应用可以同时建立多条连接：一条去工单系统，一条去文件库，另一条去数据库。

Server 不一定是远端网站。它可以在本机运行，通过标准输入输出与 AI 应用通信；也可以部署在网络上，通过 HTTP 传递消息。规范采用 JSON-RPC 这类结构化消息约定，也就是说，请求和结果都有明确字段，程序不必从一段自然语言里猜“到底要调用什么”。

连接建立时，双方还要说明各自支持哪些能力。Server 若只提供只读资料，就不应假装自己会执行工具；Client 若不支持某项能力，也不该调用它。能力协商不能保证双方所有功能都相同，但能让不兼容更早暴露，而不是等模型执行到一半才发现。

举个具体例子：客服助手需要查订单。过去，开发者可能为某个聊天产品写一个专用插件。采用 MCP 后，订单系统可以作为 Server 提供“读取订单资料”和“查询物流”能力，AI 应用作为 Host 建立连接。以后换到另一款支持 MCP 的 AI 应用，Server 定义可能继续使用；但登录、部署和审批仍可能重新配置。

Resources、Prompts 和 Tools 有什么不同？

官方规范里，Server 的三类核心原语是 Resources、Prompts 和 Tools。原语也就是说，协议里预先定义好的基本能力类型。它们都能向 AI 提供东西，但控制者和用途不同。

Resources 是资源，用于提供上下文数据，例如一份文件、数据库结构或某个业务对象。每项资源用 URI 标识，Client 可以列出并读取。你可以把“公司休假制度.pdf”暴露成资源，让 AI 在回答请假问题时读取。资源偏向“有什么资料可看”，不意味着模型有权修改原系统。

Prompts 是提示模板，用于提供一套可选择、可带参数的交互内容。例如 Server 提供“生成周报”模板，要求输入部门和日期范围，Client 取回后形成结构化消息。这里的提示词不是神奇口令，而是可复用的任务起点。按规范，Prompts 更接近由用户选择的能力，不等于模型能私自执行。

Tools 是工具，允许模型请求执行查询、计算或外部动作。每个工具应有名称、说明和输入结构。例如 get_order 要求订单号，create_ticket 要求标题和内容。它们本质上仍是工具调用：模型提出结构化请求，MCP Client 转发给 Server，Server 执行后返回结果。

三者不能混成一团。把“读取员工手册”做成资源，权限通常容易理解；把“删除员工记录”做成工具，就必须有更严格的批准和审计。官方规范明确区分工具的模型控制属性，并强调调用工具时应让人能够拒绝。协议规定了消息怎么交换，却不会替企业决定谁有删除权。

统一协议能省掉什么，又省不掉什么？

它首先减少的是重复适配。一个合规的 Server 可以向多个支持 MCP 的 Host 描述同一组工具；Host 也能用统一方法列出工具、读取资源和取得模板。对采购来说，这降低了被某个模型界面或私有插件格式锁住的程度，也让接口清单更容易盘点。

但“支持 MCP”不等于插上就完全可换。两个 Host 可能都支持 Tools，却对确认弹窗、身份登录、长任务、文件内容和错误展示采用不同做法；两个 Server 也可能把相同业务动作设计成完全不同的名称和参数。协议解决的是连接语言，不负责统一业务语义。

安全责任也不会被协议拿走。Server 能访问哪些账号？凭据存在哪里？工具结果是否含客户隐私？模型调用写操作前谁确认？这些仍要由部署者回答。若一个“查询工具”实际上可以执行任意数据库语句，工具名写得再温和也没用。应按最小权限给 Server 单独账号，并把读、写、删除分成可审计的动作。

还要区分官方规范、官方 SDK 和第三方 Server。规范告诉你合规消息应是什么；SDK 帮开发者实现；某个网上下载的 Server 则是另一位作者写的程序。它采用 MCP，不代表经过协议维护方安全审查。安装前仍要看源码、权限、维护者和网络行为。

所以采购价值不应表述成“以后换谁都不用改”。更准确的说法是：当 Host 与 Server 都遵守共同协议，并且业务能力设计得当时，连接层的一部分可以复用，迁移范围更清楚。你仍需测试身份、权限、交互和结果格式。

自己试一下

2026 年 8 月 27 日，我在当前 AI 对话环境里用下面的提示做了分类实验。你不需要安装 Server，把它发给任意 AI 聊天框即可：

某人事系统准备通过 MCP 提供四项能力：读取员工手册、按部门生成入职清单模板、查询某员工剩余年假、删除员工档案。请分别判断更适合做 Resource、Prompt 还是 Tool；对每项写出使用者、输入、可观察结果和是否必须人工确认。若信息不足，请明确提出问题。

观察模型是否把静态手册归为 Resource、把可填写的清单起点归为 Prompt、把查询和删除归为 Tool；更重要的是，它是否意识到查询涉及身份权限、删除需要强确认。本次单轮纸面重跑完成了这四项分类，并指出动态年假查询也可以设计成受控 Resource。这个结果不能证明不同产品都会采用相同分类；真实设计仍应根据控制方式、身份过滤和审计要求决定。

常见误解

第一，MCP 不是模型，也不会让模型自动变聪明；它只是规定连接和能力描述。第二，MCP 不等于传统 API 的替代品。Server 往往仍要调用原有 API，只是向 AI 应用提供统一的一层。第三，开放协议不等于每个第三方 Server 都可信。协议兼容、产品质量与安全审查是三件不同的事，不能拿一个“MCP”标签互相替代。

三句话总结

MCP 统一的是 AI 应用与外部系统交换能力和上下文的方式，不是具体业务本身。
Resources 提供资料，Prompts 提供交互模板，Tools 提供可执行动作，三者的控制方式不同。
共同协议能减少一部分重复适配，但权限、鉴权、业务语义和第三方代码仍要单独审查。

如果你要做决定

要求供应商列出它支持的 MCP 能力、传输方式、身份方案和完整工具清单，并现场把一个 Server 接到另一款兼容 Host 上。迁移演示里哪些部分能复用、哪些必须重配，比一句“全面支持 MCP”更有价值。