模型上下文协议如何帮助人工智能智能体发现并调用工具

让人工智能助手“为名为FlowAI的AI SaaS在Figma中创建一个极简的着陆页，背景为深色，包含一个标题、一个行动号召按钮以及三张功能卡片”，一个功能完善的助手就能完成这项任务：它无需你打开Figma应用，也无需任何人编写自定义的Figma集成代码，就能直接在Figma中生成页面框架。初始结果只是一个起点，你还可以通过要求添加新界面、调整排版或字体来持续迭代。同样的方法也适用于许多其他应用程序。

这引发了一些显而易见的问题：语言模型是如何控制另一款应用程序的？MCP只是另一种API而已吗？从请求到结果之间究竟发生了什么，为何这一协议会引发如此广泛的讨论？本文将逐一解答这些问题，帮助你以工程师的视角理解MCP，而非将其视为一个黑箱。

MCP是什么

MCP，即模型上下文协议，是人工智能应用发现并使用外部工具的标准方式。在 Figma 的场景中，最简单的理解方式就是一条链条：人工智能应用与 MCP 进行通信，而 MCP 再与 Figma 交互。你描述所需功能后，模型会解析该请求，查看通过 MCP 可用的工具，然后调用适合当前任务的工具。

Figma 只是一个例子。通过同一协议，人工智能应用还可以连接数据库、Slack、GitHub 以及几乎所有提供 MCP 服务器的其他系统。

在此语境下，“工具” simply指的是服务为模型提供的可供调用的功能，例如“创建框架”、“搜索消息”或“执行查询”。MCP 为这些功能提供了统一的格式，因此任何兼容的人工智能应用都能找到并使用它们。

MCP解决的集成问题

在没有统一协议的情况下，每对人工智能应用与工具都需要各自的定制代码。将一个助手连接到Figma属于一种集成，再将另一个助手连接到Figma则是另一种集成；添加Slack又是另一种集成，数据库则更是如此。集成数量会随着每个应用与每款工具的组合而不断增加，维护这些集成很快就会变得难以管理。

借助MCP，每个工具提供商只需通过该协议暴露一次其功能，每个人工智能应用也只需实现一次该协议。这样一来，任何兼容的应用都可以使用任何兼容的工具。一个便于记忆的说法是：MCP就像人工智能模型与其所需工具之间的通用适配器。

MCP能替代API吗？

不，API不会消失。Figma、Stripe和Slack仍然拥有各自的API，而你基于这些API构建的应用背后也依然存在PostgreSQL数据库。实际上，许多MCP服务器只是建立在现有API之上的薄层接口。

变化在于这些功能向AI应用呈现以及被AI应用调用的方式。在传统的集成方案中，开发者需要阅读API文档、选择合适的接口端点、编写客户端代码、处理身份验证、发送请求并解析响应。所有这些决策都是提前确定的，并固定在代码中。

借助MCP，AI应用可以在运行时向服务器询问它提供了哪些工具。一个在线商店的服务器可能会回复以下工具：

• 搜索商品
• 获取订单信息
• 创建退款请求

每个工具都配有名称、用途描述以及模型可以识别的结构化输入模式。根据用户的请求，模型会选择合适的工具，并提供符合该模式的参数。关于执行何种操作的决策从预先编写的代码转变为在接收到请求时由模型进行推理。

三个核心组成部分：主机、客户端和服务器

MCP是围绕三种角色构建的。

主机

主机是用户实际交互的AI应用：聊天助手、AI编程工具，或是以语言模型为核心功能的任何应用。它掌控着对话和模型，并决定模型可以使用哪些服务器。

MCP客户端

客户端是主机内部负责管理与MCP服务器通信的组件。根据该协议的设计，每个服务器连接通常会在主机上运行一个客户端，因此连接到Figma和GitHub的助手会维持两个独立的客户端会话。

MCP服务器

服务器向AI应用提供各种工具，并将这些工具与实际系统相连。当有工具被调用时，服务器会负责与Figma的API进行通信、执行数据库查询或发送Slack消息。

工具调用时会发生什么

将这三个角色结合在一起，流程就变得清晰了：客户端让主机能够发现服务器提供的工具，而在模型判定需要使用这些工具时，再通过结构正确的参数来调用它们。

这并非一个简单的“发送后即可忽略”的请求，而是客户端与服务器之间的对话。它们首先建立会话并确定各自的功能能力，随后客户端请求工具列表，再发送工具调用并接收相应结果。在底层，这些消息使用JSON-RPC格式传输，对于本地运行的服务器通过标准输入输出传递，而对于远程服务器则通过HTTP传递。

正是语言模型使得这种方式有别于传统的集成方式。不存在硬编码的调用顺序；模型会读取工具描述，判断哪些工具能满足用户需求，并按照对话所需的顺序依次发起请求。

以电商助手为例

假设某在线商店的客服助手其MCP服务器提供了三种工具：

• get_order

search_products

create_refund

有顾客询问：“我的订单在哪里？”模型识别出该意图，发现存在get_order工具，于是决定使用顾客的订单编号调用该工具。请求通过客户端传送到服务器，服务器查询订单数据库或内部订单API，然后返回有关该订单的结构化数据。模型再将这些数据转化为自然的回复，例如：“您的订单已于昨日发货，预计周四送达。”

客户再次联系并说：“实际上，请退款。”由于模型仍保留着对话上下文，因此它能知道“它”指的是哪一笔订单。它看到有create_refund这个功能可用，便使用相同的订单信息调用了它。如果服务器还提供了诸如notify_finance这样的工具，模型也可以在处理流程中加入该步骤。

这种分工正是MCP的核心理念：模型决定使用哪个工具以及传入什么参数，而服务器则负责执行实际操作。在生产环境中，还会在这个流程中增加一个环节：退款是一种具有后果且不可逆的操作，因此许多团队要求在执行前获得用户的明确确认或由服务器进行政策检查，而不会仅依赖模型的判断。

MCP能为你带来什么

主要有三大优势。

1. 标准化：AI应用以统一的方式与外部工具交互，无需为每次集成都采用不同的方式。
2. 灵活性：模型能够自动发现可用的工具并直接读取其结构，因此无需在冗长的系统提示中手动描述所有功能。
3. 可重用性：MCP服务器只需构建一次，即可为众多兼容的AI应用提供服务。

MCP的局限性

明确了解其限制很有必要，因为围绕该协议的炒作可能会让人忽视这些局限。

• MCP并非魔法，也无法让底层API具备超出其原有能力的功能。

这并不能让人工智能系统变得可靠。模型仍可能选择错误的工具或传递错误的参数，因此服务器端的验证机制及合理的错误处理依然至关重要。

它也无法消除认证或安全方面的问题。服务器仍需要凭证、访问控制与审计功能，而且工具的输出可能包含试图操控模型的不可信内容。

这并不意味着所有内部系统都应向人工智能代理开放。只需授予特定使用场景真正所需的最低限度的工具和权限即可。

人工智能调用API并非新鲜事；开发者多年来一直将模型与API相连。MCP带来的则是标准化接口，使得模型无需为每个工具单独进行定制化集成，就能发现并使用多种不同的工具。

核心要点

• MCP是一种用于将AI应用与工具相连的协议。它建立在API之上，而非取代它们。
• 服务器会提供带有描述和输入结构的工具信息；主机及其客户端则负责发现与通信功能。
• 模型决定调用哪个工具以及使用何种参数；实际操作则由服务器执行。
• 标准化能够将日益增多的临时集成转化为可一次构建并重复使用的组件。
• 可靠性、身份验证、最小权限原则以及高风险操作的确认仍需由您负责。

如果您是初学者，可以先将现有的MCP服务器（如GitHub、Slack或Figma的服务器）连接到您已使用的助手上，观察模型如何选择工具。一旦其价值得以体现，为内部数据库或服务构建自己的服务器便是自然而然的下一步。如需了解MCP如何融入更大的智能体框架，可阅读我们关于利用MCP在LangGraph中实现工具集成的标准化的文章。