MCP：AI工具的USB-C，一次构建处处接入

AI应用要接入Slack、GitHub和自家数据库，传统做法是逐个手写集成。10个应用配10个工具，意味着100条集成线路。Model Context Protocol（MCP）想终结这种重复劳动——把它理解为AI工具的USB-C接口：工具服务端只建一次，任何支持MCP的应用都能即插即用。

MCP要解决什么问题

据该视频讲解，在上一期内容中已经演示过tool calling：模型发出请求，由你的代码执行对应函数。但问题在于，每个工具都被硬编码进单一应用。应用数量与工具数量相乘，集成工作量呈指数级膨胀。

But every tool was hand-wired into one app.

这正是MCP的价值所在。它把「工具」从应用内部抽离出来，变成一个独立的服务端。你只需要围绕自己的API封装一个轻量Node服务，所有MCP-ready的应用就都能调用它。视频中强调的核心理念是：你构建一次工具服务端，之后处处可插拔。

要理解MCP解决的痛点，需先厘清tool calling的集成逻辑：在传统模式下，模型本身并不具备执行能力，它只能输出一段结构化的调用请求（通常以JSON描述函数名和参数），真正执行函数的是宿主应用里的代码。这意味着每个工具不仅要被定义，还必须被硬编码到某一个具体应用内部——包括函数签名、参数校验和执行逻辑。当应用从1个增长到N个、工具从1个增长到M个，就需要维护N×M套集成代码，且任何工具的升级都要在N个应用里同步修改。这种耦合让工具无法跨应用流动，正是MCP试图通过"服务端独立化"打破的瓶颈。

MCP的工作流程

MCP采用客户端-服务端架构，把模型与工具执行彻底解耦。你的AI应用内部内置一个MCP客户端，整个交互分四步。

第一步：客户端问服务端有什么工具

客户端先向MCP服务端发起询问：你提供哪些工具？

You build a tool server once.

第二步：服务端返回工具清单

服务端回复工具的名称、描述和输入schema（输入模式）。这份结构化清单让模型知道每个工具能做什么、需要什么参数。

The server replies with names, description, input schemas.

输入schema通常遵循JSON Schema规范，用来精确描述工具接受的参数：比如一个create_issue工具会声明需要title（字符串、必填）、body（字符串、可选）、labels（字符串数组、可选）。这份schema的作用不只是给模型"看"，它同时充当了契约——客户端据此校验模型生成的参数是否合法，服务端也能拒绝不符合schema的请求。相比自然语言描述，结构化schema让模型能更可靠地生成正确参数，也降低了工具调用失败的概率，这是MCP区别于"把工具文档塞进prompt"的关键工程细节。

第三步：客户端把清单交给模型

客户端将这份工具列表传递给模型。模型据此判断该调用哪个工具。

第四步：模型选定后，客户端代为调用

当模型选中某个工具，客户端会向服务端发起调用请求。服务端执行实际工作，把结果回传给客户端。关键点在于：模型从不直接与服务端对话。

The model never talks to the server directly.

这条「模型—客户端—服务端」的链路设计，把安全边界和执行职责清晰分开。模型只负责决策，客户端负责中转，服务端负责执行。

服务端能提供什么：工具、资源与提示词

MCP服务端并非只能暴露「工具」。视频指出，一个服务端可以同时提供三类能力：

Tools（工具）：代表可执行的动作，比如发送消息、创建issue、写入数据库。
Resources（资源）：代表数据本身，供模型读取和参考。
Prompts（提示词）：代表模板化的指令，用来规范特定场景下的交互方式。

把这三类能力分开理解很重要。工具是「做」，资源是「看」，提示词是「怎么问」。一个设计良好的MCP服务端，往往同时覆盖这三层，让接入方拿到的是完整的能力封装，而不只是几个孤立的函数。

这三类能力之所以分开，源于MCP的一个设计取向：把"可执行动作"与"可读上下文"解耦。Tools是模型主动触发的动作，通常有副作用（写数据、发消息）；Resources则是被动供模型读取的数据片段，比如一份文档、一条数据库记录或一个文件内容，它们通过URI标识、可被订阅或按需拉取；Prompts是可复用的指令模板，常由用户在界面中主动选择。这种分层让接入方可以按需授权——例如只授予Resources读取权限而不给Tools写权限，从而在安全上做更细粒度的控制，而不是像传统做法那样一旦接入就暴露全部函数。

为什么这是AI工程的关键一步

从工程视角看，MCP处理的是集成层的复用问题。tool calling解决了「模型如何触发代码」，MCP则解决了「这段代码如何被无数应用共享」。前者是能力问题，后者是规模化问题。

对开发者而言，最直接的收益是：不再为每个AI应用重写一遍Slack集成、GitHub集成和数据库集成。你把自己的API包成一个Node服务，接上MCP，之后无论是用Angular还是React写的agent，都能直接复用同一套工具服务端。视频结尾也预告了下一步——用Angular和React构建一个真实的AI agent。

如果说tool calling是让模型学会「伸手」，那MCP就是给整个生态定了一套标准的插座规格。接口统一之后，工具才能真正流动起来。