MCP 入门：Agent、MCP Client、MCP Server 和外部工具到底是什么关系？

在使用 Dify、Claude、Cursor 等 AI 应用时，我们经常会看到“配置 MCP”“添加 MCP Server”“选择 MCP 工具”等概念。

这些名字看起来很复杂，但 MCP 解决的核心问题其实很简单：

让 Agent 能够用统一的方式发现和调用外部工具。

本文从实际使用场景出发，梳理 Agent、MCP Client、MCP Server、外部工具以及 API Key 之间的关系。

一、为什么 Agent 需要外部工具？

大模型擅长理解语言、分析问题和生成内容，但它本身通常无法直接操作现实中的业务系统。

例如，仅靠大模型本身无法可靠地完成这些事情：

查询 GitLab 项目中的 Issue
创建 Jira 缺陷
查询数据库中的订单
获取实时天气
读取企业内部文档
调用业务系统创建退款单

这些能力需要由外部系统提供。对于 Agent 来说，可以调用的具体能力就是“工具”。

例如，一个 GitLab 工具集合可能包含：

list_issues：查询 Issue
create_issue：创建 Issue
get_merge_request：查询合并请求
create_merge_request：创建合并请求

大模型负责判断“什么时候该用哪个工具”，真正的数据查询或业务操作则由工具完成。

二、外部工具和 MCP Server 是什么关系？

可以把 MCP Server 理解成一个工具箱，外部工具则是工具箱中的具体工具。

MCP Server（工具箱）
├── list_issues（查询 Issue）
├── create_issue（创建 Issue）
├── get_project（查询项目）
└── create_merge_request（创建合并请求）

MCP Server 主要负责：

告诉客户端自己提供了哪些工具。
描述每个工具的用途和参数格式。
接收工具调用请求。
执行背后的函数或调用第三方 API。
将执行结果返回给客户端。

因此，外部工具是具体能力，MCP Server 是按照 MCP 标准对外发布和执行这些能力的服务。

三、Agent 是怎么调用 MCP 工具的？

严格来说，并不是大模型直接连接 MCP Server，而是 Agent 所在的宿主应用提供 MCP Client。

完整调用链如下：

用户
  ↓ 自然语言指令
Agent / 大模型
  ↓ 判断需要调用哪个工具
MCP Client（位于 Dify、Claude、Cursor 等宿主应用中）
  ↓ 使用 MCP 协议通信
第三方 MCP Server
  ↓ 调用函数、数据库或第三方 API
GitLab、Jira、数据库等外部系统

MCP 工具调用链

各组件的职责分别是：

1. 大模型

大模型负责理解用户意图、选择合适的工具、生成调用参数，以及把工具返回的数据整理成自然语言。

2. Agent

Agent 负责组织整个执行过程，包括模型推理、工具选择、工具调用、结果观察以及必要时的重复调用。

3. MCP Client

MCP Client 通常是 Dify、Claude、Cursor 等宿主应用中的组件。它负责：

连接 MCP Server
获取工具列表及工具定义
向 MCP Server 发送工具调用请求
接收 MCP Server 返回的结果

4. MCP Server

MCP Server 把现有函数、服务或第三方 API 封装成符合 MCP 标准的工具，并负责执行这些工具。

5. 外部系统

外部系统是真正保存数据或完成业务操作的地方，例如 GitLab、Jira、数据库、文件系统和企业内部平台。

MCP Host、MCP Client、MCP Server 的三层关系

MCP 的完整架构还可以概括为三个角色：

MCP Host：承载 AI 和 Agent 的应用，例如 Dify、Claude Desktop、Cursor。
MCP Client：内嵌于 Host，负责按照 MCP 协议连接 Server、发现并调用能力。
MCP Server：向 Client 提供 Tools、Resources、Prompts，并对接本地或远程系统。

需要注意：MCP Client 主要负责协议通信；理解用户意图和决定调用哪个工具，通常由大模型及 Agent 编排逻辑完成。

四、以 GitLab MCP 为例

假设 GitLab 官方或第三方提供了一个 GitLab MCP Server，它对外暴露查询 Issue、创建 Issue、读取项目等工具。

用户向 Agent 提出：

帮我查询项目中尚未关闭的 Issue。

背后的过程大致如下：

MCP Client 连接 GitLab MCP Server，并获取其工具列表。
GitLab MCP Server 返回 list_issues 等工具的名称、说明和参数定义。
大模型根据用户的问题，选择 list_issues 工具。
大模型生成项目名称、Issue 状态等调用参数。
MCP Client 按照 MCP 协议把请求发送给 GitLab MCP Server。
GitLab MCP Server 使用 GitLab Access Token 调用 GitLab API。
GitLab API 返回 Issue 数据。
MCP Server 将数据返回给 MCP Client。
Agent 再让大模型把数据整理成用户容易理解的回答。

因此，可以准确地描述为：

Agent 通过宿主平台中的 MCP Client，按照 MCP 协议调用第三方提供的 MCP Server；MCP Server 再通过 API 或内部代码操作第三方系统。

五、已有工具时，是否需要编写 MCP Server？

如果已经有一个函数或业务接口，并希望多个 AI 客户端都能以统一方式调用它，可以在外面封装一层 MCP Server。

例如已有函数：

def query_order(order_id):
    return {"order_id": order_id, "status": "paid"}

将它包装成 MCP 工具后，可以表示为：

订单 MCP Server
└── query_order
    ├── 用途：根据订单号查询订单状态
    ├── 参数：order_id
    └── 实际执行：调用原有 query_order 函数

之后，支持 MCP 的 Agent 就能发现并调用 query_order。

通常没有必要为每一个工具单独启动一个 MCP Server。更常见的方式是按照业务领域分组：

订单 MCP Server
├── query_order
├── cancel_order
├── query_refund
└── create_refund

是否需要封装成 MCP Server，要根据使用场景判断：

现有能力	推荐接入方式
已经是 MCP Server	直接配置连接
Python、Java 等本地函数	可封装为 MCP Server
已有 HTTP API	可封装为 MCP Server，也可直接通过 HTTP/OpenAPI 工具接入
只给一个 Dify 应用使用	使用 Dify 自定义工具可能更简单
希望同时供 Dify、Claude、Cursor 等使用	更适合封装为 MCP Server

MCP 不是唯一的工具接入方案。它最大的价值是提供统一标准，减少不同 AI 平台重复适配的成本。

六、MCP 中为什么还会出现 API Key？

配置 MCP 时经常也会看到 API Key，需要注意它可能和大模型 API Key 完全不同。

大模型 API Key

用于授权 Dify 等应用调用模型服务，例如：

Gemini API Key
OpenAI API Key
DeepSeek API Key
通义千问 API Key

它解决的是“能不能调用大模型”的问题。

MCP 服务的 API Key 或 Token

用于授权 MCP Client 访问 MCP Server，或者让 MCP Server 访问背后的第三方系统。

例如，GitLab MCP Server 可能需要 GitLab Access Token，才能读取对应项目或创建 Issue。

它解决的是“能不能访问和操作外部工具”的问题。

可以简单记忆：

大模型 API Key：进入模型的钥匙
MCP API Key：连接 MCP 服务的钥匙
GitLab Token：操作 GitLab 资源的钥匙

具体实现中，MCP Server 的访问凭证和第三方系统的访问凭证可能是同一个，也可能是两层不同的凭证，取决于服务的架构设计。

七、Function Calling 和 ReAct 有什么区别？

在 Dify Agent 中配置 MCP 工具时，通常还需要选择工具调用策略。

Function Calling

模型直接返回要调用的工具和结构化参数，平台执行工具后再将结果交给模型。

适合：

单步骤任务
工具和参数比较明确
更关注速度和稳定性

ReAct

模型按照“判断—行动—观察结果”的方式循环执行，可以根据上一次工具结果继续选择下一个工具。

适合：

多步骤任务
需要组合多个工具
需要根据中间结果调整计划
可能需要重试的任务

初次接入时通常可以先使用 Function Calling；当任务需要多步推理和连续调用工具时，再考虑 ReAct。

八、在 Dify 中接入 MCP 的整体过程

以 Dify 为例，整体配置过程可以概括为：

准备一个可访问的 MCP Server。
确保部署 Dify 的主机能够访问 MCP Server 的地址和端口。
在 Dify 中安装支持 MCP 的连接插件和 Agent 策略。
新建 Chatflow，并添加 Agent 节点。
给 Agent 配置一个已经接入的大模型。
配置 MCP Server 地址及认证信息。
从 MCP Server 提供的工具列表中选择需要授权给 Agent 的工具。
在系统提示词中说明什么场景下应该调用什么工具。
运行并验证 Agent 能否正确选择工具、传递参数并获得结果。

需要特别注意：配置成功不仅要求页面上填写正确，还要求 Dify 所在网络能够访问 MCP Server。

九、总结

理解 MCP，可以抓住下面几句话：

外部工具是某项具体能力，例如查询 Issue 或查询订单。
MCP Server 是提供这些工具的标准化服务。
MCP Client 位于 Agent 的宿主应用中，负责连接和调用 MCP Server。
Agent 和大模型负责理解用户需求并决定调用哪个工具。
MCP Server 负责真正执行工具，并访问 GitLab、数据库等外部系统。
大模型 API Key 和 MCP/第三方系统的认证凭证不是一回事。

最后，可以用一句话概括整个调用链：

用户向 Agent 提出需求，大模型决定调用工具，宿主应用中的 MCP Client 按照 MCP 协议请求 MCP Server，MCP Server 操作外部系统并把结果返回给 Agent。

如果把大模型比作“大脑”，那么外部工具就是“手脚”，MCP Server 是“标准化工具箱”，MCP Client 则是 Agent 打开和使用工具箱的方式。

一、为什么 Agent 需要外部工具？#

二、外部工具和 MCP Server 是什么关系？#

三、Agent 是怎么调用 MCP 工具的？#

1. 大模型#

2. Agent#

3. MCP Client#

4. MCP Server#

5. 外部系统#

MCP Host、MCP Client、MCP Server 的三层关系#

四、以 GitLab MCP 为例#

五、已有工具时，是否需要编写 MCP Server？#

六、MCP 中为什么还会出现 API Key？#

大模型 API Key#

MCP 服务的 API Key 或 Token#

七、Function Calling 和 ReAct 有什么区别？#

Function Calling#

ReAct#

八、在 Dify 中接入 MCP 的整体过程#

九、总结#