MCP Server 是什么

它解决的是「接工具」这件事

没有 MCP 时，每接一个外部能力（查数据库、读文件、调内部 API）， 你都要在应用里为它写一套对接代码：定义参数、拼提示、解析返回。

MCP 把这个过程标准化成三层：

• Server：把能力包装成标准接口（有哪些工具、参数是什么）；
• Client：宿主程序里负责连接 server 的那部分；
• 模型：看到工具清单后，决定调哪个、传什么参数。

于是同一个 server 可以被不同客户端复用，不用为每个应用重写一遍。

一次调用长什么样

1. 客户端连上 server，拉取工具清单（名字、说明、参数 schema）。
2. 用户提问，宿主把清单随请求一起给模型。
3. 模型决定调用某个工具，返回「调用意图」。
4. 客户端真的去执行，把结果回传给模型。
5. 模型基于结果继续回答，或再调下一个工具。

注意第 3、4 步是分开的：模型只说想调什么，真正执行的是客户端。 这条分界线是安全控制的落点。

传输方式

协议本身不绑定传输。常见两种：

方式	场景
标准输入输出（stdio）	本地进程，客户端把 server 当子进程拉起
HTTP	远程服务，多人共用或需要独立部署

本地场景多用 stdio，因为它不需要端口和鉴权；远程共享才需要 HTTP 加认证。

自己写一个 server 时要注意

• 工具说明写给模型看：名称和描述决定模型会不会选它，含糊的描述等于没接。
• 参数 schema 要收紧：范围、枚举、必填写清楚，减少模型瞎填。
• 返回要短：工具结果会进上下文，一次返回几万字会挤掉真正的内容。
• 权限在 server 侧把关：不要假设模型不会调用危险工具，白名单写在 server 里。

常见误解

• 「MCP 是模型的能力」：模型不知道 MCP，它只看到工具清单；协议是客户端和 server 之间的事。
• 「接了 MCP 就能自动用」：还要宿主支持 MCP 客户端，并在会话里启用这个 server。
• 「MCP 等于插件」：插件通常是某个产品私有的，MCP 是跨产品的协议。

下一步

• 协议本身：MCP
• 自己接一个：接一个 MCP Server
• 工具调用的基础：工具调用