MCP 是什么？

在 MCP 之前，要让模型连上一个数据源，就得把这段集成写在你自己的应用里。每个应用都得写一份。十个应用想要同样的五个集成，就是同一件事实现五十遍。

Model Context Protocol（MCP）把这层接口标准化了。服务器写一次，任何兼容的客户端都能用。

基本形态

MCP 是一个客户端-服务器协议。

服务器暴露能力——文件系统服务器、数据库服务器、工单服务器。每个都声明自己提供什么，并处理请求。

客户端是挂着模型的应用。客户端发现服务器提供什么，再把这些能力作为工具交给模型使用。

解耦才是重点。服务器不知道会是哪个模型、哪个应用来用它；客户端也不了解服务器的内部。双方各自实现一套协议，而不是 N 个集成。

服务器可以本地跑成一个子进程，也可以远程走 HTTP。本地常见于文件系统和开发者工具，远程则用于共享服务。

三类能力

工具——模型可以调用的函数。查数据库、建工单、读文件。它们直接对应普通的工具调用；MCP 标准化的是工具如何被发现，而不是如何被调用。

资源——客户端可以读取并放进上下文的数据。一个文件、一份 schema、一个文档。不是被调用，而是被取回。

prompt——服务器为针对它的常见操作提供的可复用模板。

实际用起来，最重要的是工具。

改变了什么，没改变什么

没改变： 模型仍然只发出请求，执行依旧在它之外发生。每一条安全考量都不变——校验参数，权限按人而不是按请求来判，不可逆操作要设闸。

改变了： 集成代码放在哪、由谁来写。厂商可以只发一个 MCP 服务器，而不用为每个 AI 应用各做一个插件。发现变成动态的——客户端可以在运行时问服务器它提供什么。

实际效果是共享生态，而不是一个个按应用隔开的孤岛。

什么时候值得用

可复用的集成。 一次写好的数据库服务器，服务所有兼容的客户端。

本地数据访问。 本地服务器能碰到托管模型厂商根本看不到的文件和服务。数据留在你机器上，只有工具调用和结果穿过边界。

厂商提供的接入。 发布一个 MCP 服务器，是让产品能被各种 AI 应用普遍使用的一个合理做法。

组合。 同时接多个服务器——文件系统、数据库、工单——由客户端把并集呈现给模型。

什么时候没必要用

一个应用里只有一个集成。 只有一个工具、一个使用方时，这套协议就是额外开销。直接把工具定义出来就行。

对延迟敏感的关键路径。 多一个进程和一次协议跳转，开销虽小但确实存在。

工具泛滥。 MCP 让加工具变得容易，也就容易加太多。相似工具超过十来个，选择准确率就会下降，而接五个各带八个工具的服务器，正好就是这种情况。应该路由到相关的子集，而不是把所有工具都暴露出去。

有必要明说的安全问题

MCP 并不解决 agent 安全问题，而集成的便利反而会掩盖风险。

服务器就是你在跑的代码。 第三方服务器拥有你授予它的全部权限。把它当成任何一个依赖来对待。

工具描述来自服务器，并会进入模型的上下文。恶意或被攻陷的服务器可以借这些描述塑造模型的行为。

服务器返回的结果是不可信文本。 返回网页内容或用户提交数据的服务器，就是一个提示注入通道，和任何其他工具没有区别。

权限依然归你管。 协议本身不强制当前用户能做什么。这道检查刻意留在了你的客户端或服务器里。

要点回顾

• MCP 标准化了模型发现和使用工具的方式，集成因此写一次就够，不必按应用各写一遍。
• 服务器暴露 工具、资源 和 prompt；客户端把它们呈现给模型。
• 执行和安全模型都没变——模型仍然只负责发请求。
• 可复用集成、本地数据访问和组合场景值得用；单应用单工具则纯属开销。
• 服务器是有权限的依赖，它们的描述会进入你的上下文，返回结果不可信。

下一篇： 你的第一次 LLM API 调用