第十章：模型上下文协议
要让大语言模型成为高效的智能体，仅具备多模态生成能力是不够的。智能体还需要与外部环境交互，比如获取实时数据、调用外部软件、执行具体操作。模型上下文协议（MCP）正是为此而生，它为大语言模型与外部资源的交互提供了标准化接口，是实现一致、可预测集成的关键机制。
想象一个通用适配器，能让任何大语言模型轻松接入各种外部系统、数据库或工具，而无需为每个系统单独开发定制方案——这正是 MCP 的核心价值。MCP 是一个开放标准，统一规范了 Gemini、OpenAI GPT、Mixtral 和 Claude 等主流大语言模型与外部应用、数据源、工具之间的通信方式。可以将它理解为通用连接机制，极大简化了大语言模型获取上下文、执行操作、与系统交互的过程。
MCP 基于「客户端 - 服务器」架构运行。协议明确定义了 MCP 服务器如何对外提供三类核心元素：数据（称为资源）、交互模板（本质上是提示词）、可执行功能（称为工具）。MCP 客户端会使用这些元素，这里的客户端可以是 LLM 应用，也可以是 AI 智能体本身。这种标准化架构极大简化了将 LLM 集成到不同操作环境的复杂度。
不过需要认识到，MCP 本质上是一个「智能体接口」的协议规范，其实际效果很大程度上取决于底层 API 的设计质量。这里存在一个潜在风险：开发者可能只是简单地将现有的老旧 API 套上 MCP 外壳，而没有针对智能体的特殊需求进行优化。举个例子，假如某个票务系统的 API 只支持逐个查询工单详情，那么当智能体需要汇总大量高优先级工单时，就会因为频繁调用而变得缓慢且不准确。
要让智能体真正发挥效能，底层 API 需要针对性改进，增加过滤、排序等确定性功能，帮助非确定性的 AI 智能体更高效工作。这说明了一个重要原则：AI 智能体无法神奇地取代传统的确定性工作流程，反而往往需要更强大的确定性支持才能成功。
还需要注意，MCP 虽然能够封装各种 API，但这些 API 的输入输出格式未必是智能体能够理解的。一个 API 要真正有用，其数据格式必须对智能体友好，而这一点 MCP 协议本身无法强制保证。
举个例子：若为文档存储系统创建的 MCP 服务器只返回 PDF 文件，而智能体无法解析 PDF 内容，那么这样的设计没有什么实际意义。更好的做法是先构建能返回文本版本（如 Markdown 格式）的 API，让智能体能真正读取和处理内容。这揭示了一个重要原则：设计 MCP 集成时，不能只关注连接机制，更要深入考虑数据交换的本质，才能确保真正的兼容性和实用性。
MCP 与工具函数调用
模型上下文协议（MCP）与工具函数调用是两种不同的技术机制，它们都能够让大语言模型与外部能力（包括各类工具）进行交互并执行具体操作。尽管这两种技术都致力于增强 LLM 的能力，使其不再局限于单纯的文本生成，但它们在实现方法和抽象层级上存在显著差异。
工具函数调用本质上是大语言模型向特定预定义工具或功能发出的直接调用请求。需要说明的是，在技术语境下，「工具」和「函数」这两个术语通常可互换使用，指的是同一类可执行的外部能力。
这种交互模式的核心特征是一对一通信架构：LLM 首先基于对用户意图的理解（特别是需要外部能力才能完成的请求），按既定格式构造调用请求；随后，应用程序代码接收并执行请求，最终将结果返回给 LLM 处理。当前工具函数调用的具体实现往往是各 LLM 平台厂商的专有方案，不同提供商之间的实现方式和接口规范存在明显差异和不兼容性。
相比之下，MCP 是用于大语言模型发现、通信和利用外部能力的标准化接口。作为开放协议，它促进了 LLM 与广泛工具、系统的交互，旨在建立一个开放生态，让任何兼容工具都可被任何兼容 LLM 访问。这使得不同系统可以相互连接、灵活组合、反复利用。
通过采用这种去中心化的协作模式，MCP 显著提高了系统互通性，让既有服务焕发新价值。这一策略的优势在于：只需为老旧或异构服务包装一层 MCP 兼容接口，就能将它们接入现代 AI 生态。这些服务继续独立运行，但现在可以组合成新的应用和工作流，由 LLM 统一调度。这种方式无需昂贵的系统重写，就能提升整体灵活性和可重用性。
以下是 MCP 与工具函数调用之间基本区别的详细分析：
特性
工具函数调用
模型上下文协议（MCP）
标准化程度
厂商专有实现，不同 LLM 提供商采用各自的格式和实现方案。
开放的标准化协议，推动不同 LLM 与工具间的互操作能力。
功能范围
LLM 直接调用执行特定预定义功能的机制。
构建 LLM 与外部工具发现和通信的完整框架体系。
系统架构
LLM 与应用工具处理逻辑间的点对点直接交互。
基于「客户端 - 服务器」架构，支持 LLM 应用连接多种 MCP 服务器。
发现机制
在会话上下文中静态配置可用工具列表。
支持工具能力的动态发现和查询机制。
可复用性
工具集成与特定应用和 LLM 平台深度绑定。
推动可独立部署的 MCP 服务器开发，支持跨平台复用。
可以将工具函数调用类比为一套为 AI 专门定制的工具，比如特定的扳手和螺丝刀。这种方案对执行固定任务集合的工作环境十分高效。相比之下，MCP 则类似于建立一套通用化、标准化的电源接口系统。MCP 本身不直接提供具体工具，而是构建开放的基础设施，允许任何厂商生产的兼容设备都能接入并正常工作，从而打造一个能够动态扩展、持续演进的工具生态系统。
简而言之，函数调用提供对有限特定功能的直接访问，而 MCP 则构建了标准化通信框架，使 LLM 能够发现并利用广泛的外部资源生态系统。
对于功能需求简单的应用，专用工具集已足够；但对于需要高度适应性、涉及多系统复杂交互的 AI 应用，采用 MCP 这样的通用标准协议是构建可持续演进架构的关键。
MCP 的其他考虑因素
虽然 MCP 提供了强大的功能，但要在特定场景中充分评估其适用性，还需要考虑几个关键因素。下面我们来详细了解这些方面：
工具 vs. 资源 vs. 提示词： 理解这些组件各自的角色很关键。资源指的是静态数据（比如 PDF 文件或数据库记录），工具则是可以执行操作的功能（比如发送邮件或调用 API），而提示词就像是指导 LLM 如何与资源或工具进行交互的模板，确保整个交互过程既规范又高效。
可发现性： MCP 的一大优势是，客户端能够实时查询服务器，动态获取可用的工具和资源列表。这种「即时发现」的机制特别适合需要灵活适应新功能而无需重新部署的智能体。
安全性： 无论通过什么协议开放工具和数据，都需要完善的安全保障。MCP 的实现必须包含身份验证和权限控制，确保只有授权客户端才能访问指定服务器，并限定其可执行的操作范围。
实现： 尽管 MCP 是开放标准，但实际落地可能较为复杂。好在一些厂商正在简化这个过程，比如 Anthropic 和 FastMCP 等模型提供商推出的 SDK，帮助开发者处理了大量模板代码，让创建和连接 MCP 客户端与服务器变得更轻松。
错误处理： 一套完善的错误处理机制非常重要。协议需要明确规定如何将各种错误情况（比如工具执行失败、服务器无法连接或者请求格式有误）清晰地反馈给 LLM，这样它才能理解问题所在，并尝试其他的解决方案。
本地 vs. 远程服务器： MCP 服务器既可以部署在智能体所在的本地机器上，也可以放在远程服务器中。本地部署通常用于追求更快响应速度和更好保护敏感数据；远程架构则更适合需要在组织内共享工具资源、支持灵活扩展的场景。
按需 vs. 批处理： MCP 既支持实时交互的按需调用，也能应对大规模的批量处理。具体选择哪种方式要看实际应用需求，可能是需要即时反馈的对话型智能体，也可能是对数据记录进行批处理的分析流程。
传输机制： 协议还定义了底层的通信传输层。对于本地交互，可以使用基于 JSON-RPC 的标准输入/输出来实现高效的进程间通信。对于远程连接，则采用 Streamable HTTP 和服务器发送事件（SSE）等 Web 友好协议，以实现持久、高效的「客户端 - 服务器」通信。
MCP 采用「客户端 - 服务器」模型来标准化信息流。理解各组件如何交互，是掌握 MCP 高级智能体行为的关键：
大语言模型（LLM）： 作为整个系统的智能核心，它负责处理用户请求、制定执行计划，并判断何时需要调用外部资源或执行具体操作。
MCP 客户端： 这是一个包装了 LLM 的应用程序，扮演中间人角色，将 LLM 的意图转化为符合 MCP 标准的请求。它的主要职责是发现可用的 MCP 服务器、建立连接并维护通信。
MCP 服务器： 相当于通往外部世界的桥梁，向经过授权的 MCP 客户端开放一系列工具、资源和提示模板。每个服务器通常专注于某个特定领域，比如对接企业内部的数据库系统、邮件服务平台或者公共 API 接口。
可选的第三方服务： 这些是 MCP 服务器实际管理和对接的外部工具、应用或数据源，也是最终执行具体操作的终端。无论是查询专有数据库、与 SaaS 平台进行交互，还是调用天气 API 获取实时数据，都是通过这些第三方服务来完成的。
核心交互流程如下：
发现阶段： MCP 客户端会代表 LLM 去查询 MCP 服务器，了解它具体提供哪些能力。服务器会返回一份清单，详细列出可用的工具（例如 send_email）、资源（例如 customer_database）和提示词。
请求构建： LLM 根据需求决定要使用哪个工具，比如说想要发送邮件。它会构建一个具体的请求，明确指定要调用的工具（send_email）以及必要的参数信息（收件人、邮件主题、正文内容等）。
客户端通信： MCP 客户端拿到 LLM 构建好的请求后，会按照标准格式将这个调用请求发送给对应的 MCP 服务器。
服务器执行： MCP 服务器收到请求后，会先进行客户端身份验证和请求合法性检查，确认无误后才会通过底层软件接口（比如调用邮件 API 的 send() 函数）来执行具体的操作。
响应和上下文更新： 操作执行完成后，MCP 服务器会按照标准格式将响应结果返回给 MCP 客户端。这个响应会告诉客户端操作是否成功，并附带相关的输出信息（比如发送邮件后得到的确认编号）。客户端随后将这些结果反馈给 LLM，帮助它更新当前的任务上下文，为下一步操作做好准备。
实际应用场景
MCP 极大拓展了 AI 和大语言模型的应用范围，使其更加灵活强大。以下是九个典型应用场景：
数据库集成： 通过 MCP，LLM 和智能体能够轻松对接数据库中的结构化数据并进行交互。比如借助 MCP 数据库工具箱，智能体可以直接用自然语言指令来查询 Google BigQuery 数据集，实时获取信息、生成报表或者更新记录。
生成式媒体编排： MCP 让智能体能够整合各类先进的生成式媒体服务。通过 MCP 媒体生成工具，智能体可以调用 Google Imagen 生成图片、使用 Google Veo 制作视频、通过 Google Chirp 3 HD 合成语音、或利用 Google Lyria 创作音乐，为 AI 应用提供动态内容创作能力。
外部 API 交互： MCP 为 LLM 提供了标准化的外部 API 调用方式。智能体可以获取实时天气、查询股价、发送邮件，还能与 CRM 系统等业务平台对接，大幅拓展语言模型的应用范围。
基于推理的信息提取： 借助 LLM 强大的推理能力，MCP 实现了比传统搜索更高效的信息提取。传统搜索只能返回整篇文档，而智能体能深入分析文本，精准提取出直接回答用户问题的具体条款、数据或关键陈述。
自定义工具开发： 开发者可以基于实际需求构建专属工具，并通过 MCP 服务器（比如使用 FastMCP）对外开放。这样就能把企业内部的专业功能或私有系统以标准化、易用的方式提供给 LLM 和各种智能体，无需对 LLM 本身进行任何修改。
标准化通信桥梁： MCP 在 LLM 和应用程序之间建立了一个统一的通信层，不仅降低了系统集成的复杂度，还促进了不同 LLM 提供商和应用平台之间的互操作性，让开发复杂的智能体系统变得更加简单高效。
复杂工作流编排： 通过整合多个 MCP 开放的工具和数据源，智能体能够协调执行高度复杂的多步骤工作流程。例如，它可以从数据库提取客户信息，自动生成个性化的营销图片，撰写定制化的邮件内容，最后完成发送，整个过程都是通过调用不同的 MCP 服务来实现。
物联网设备控制： MCP 还可以帮助 LLM 与物联网设备进行交互。智能体能够通过 MCP 向智能家居设备、工业传感器或机器人发送控制指令，实现对物理系统的自然语言控制和自动化管理。
金融服务自动化： 在金融领域，MCP 让 LLM 能够对接各种金融数据源、交易平台和合规系统。智能体可以分析市场行情、执行交易指令、提供个性化的理财建议，或者自动完成监管报表，同时确保所有通信都符合安全标准和规范要求。
简而言之，MCP 让智能体能够实时获取来自数据库、API 和网络资源的信息，还能够通过整合处理多方数据来执行发送邮件、更新记录、控制设备、完成复杂任务等操作。此外，MCP 还支持各类媒体生成工具，为 AI 应用提供更丰富的能力。
实战示例：使用 Google ADK
本节内容将演示智能体如何连接到提供文件系统操作的本地 MCP 服务器，使其能够与本地文件系统进行交互。
智能体设置：使用 MCPToolset
想要让智能体具备文件系统交互能力，需要先创建一个 agent.py 文件（例如放在 ./adk_agent_samples/mcp_agent/agent.py 目录下）。MCPToolset 在 LlmAgent 对象的 tools 列表中实例化。这里有个特别需要注意的地方：记得把 args 列表里的 "/path/to/your/folder" 替换成你本地系统上一个真实存在的目录绝对路径，而且要确保 MCP 服务器有权限访问这个目录。这个目录会作为智能体进行文件操作时的根目录。
npx（Node Package Execute）是 npm 5.2.0 及更高版本内置的工具，能够直接运行 npm registry 中的 Node.js 包，无需全局安装。它本质上是一个 npm 包运行器，常用于运行以 Node.js 包形式发布的社区 MCP 服务器。
为了让智能体开发套件（ADK）能够正确识别 agent.py 文件作为可发现的 Python 包，我们需要创建一个 init.py 文件。这个文件需要和 agent.py 放在同一个目录下。
当然，还有其他支持的命令可供使用。例如，可以按如下方式连接到 python3：
在 Python 上下文中，UVX 是基于 uv 的命令行工具，用于在临时隔离的 Python 环境中执行命令。它允许直接运行 Python 工具和包，无需全局安装或影响项目环境，并可通过 MCP 服务器调用。
现在 MCP 服务器已经搭建完成，下一步就是建立连接了。
使用 ADK Web 连接 MCP 服务器
首先执行 adk web 命令。在终端中导航到 mcp_agent 的父目录（例如 adk_agent_samples）并运行：
等浏览器里显示出 ADK Web 的操作界面后，从智能体菜单里选择 filesystem_assistant_agent。接下来你可以试试下面这些指令：
「显示此文件夹的内容。」
「读取 sample.txt 文件。」（假设 sample.txt 位于 TARGET_FOLDER_PATH。）
「another_file.md 里有什么？」
使用 FastMCP 创建 MCP 服务器
FastMCP 是一个专门为简化 MCP 服务器开发而设计的高级 Python 框架。它通过提供抽象层来封装协议的复杂性，让开发者能够把精力集中在核心业务逻辑上。
这个库最大的特点是可以用简单的 Python 装饰器来快速定义工具、资源和提示模板。特别值得一提的是它的模式自动生成功能，它会智能地解析 Python 函数的签名、类型注解和文档字符串，自动生成 AI 模型所需的接口规范，这种自动化机制大大减少了手动配置的工作量，也降低了出错的可能性。
除了基础的工具创建功能，FastMCP 还支持像服务器组合和代理这样的高级架构模式。这意味着你可以用模块化的方式开发复杂的多组件系统，还能把现有的服务无缝对接到 AI 可访问的框架里。另外，FastMCP 还内置了对高效、分布式、可扩展的 AI 驱动应用的优化支持。
使用 FastMCP 设置服务器
举个简单的例子，假设服务器提供了一个基础的「问候」功能。等服务器启动运行后，ADK 智能体和其他 MCP 客户端就能通过 HTTP 协议来调用这个功能了。
这个 Python 脚本定义了一个名为 greet 的函数，根据人名生成个性化问候语。函数上方的 @tool() 装饰器会自动将其注册为 AI 或其他程序可调用的工具。FastMCP 利用函数的注释以及类型注解，自动告知智能体工具的使用方法、所需参数和返回结果。
运行此脚本时，会启动一个 FastMCP 服务器，在 localhost:8000 监听请求。这样 greet 函数就成为可通过网络访问的服务。我们可以配置智能体连接到此服务器，在完成复杂任务的过程中调用问候功能。服务器将持续运行，直到手动停止。
使用 ADK 智能体连接 FastMCP 服务器
可以将 ADK 智能体配置为 MCP 客户端，使其能够使用正在运行的 FastMCP 服务器。具体做法是用 FastMCP 服务器的网络地址（通常是 http://localhost:8000）来配置 HttpServerParameters。
还可以添加 tool_filter 参数，限制智能体只能使用服务器提供的特定工具，比如 greet 问候功能。当用户发出「问候 John Doe」这样的请求时，智能体内置的大语言模型会识别通过 MCP 可用的 greet 工具，用「John Doe」作为参数调用，最后将服务器响应返回给用户。这展示了如何将通过 MCP 暴露的自定义工具集成到 ADK 智能体。
要实现这样的配置，我们需要准备一个智能体配置文件（比如放在 ./adk_agent_samples/fastmcp_client_agent/ 目录下的 agent.py）。这个文件会创建一个 ADK 智能体实例，并通过 HttpServerParameters 来和正在运行的 FastMCP 服务器建立连接。
该脚本定义了一个名为 fastmcp_greeter_agent 的智能体，基于 Gemini 模型。智能体被设定为友好助手，专门负责问候用户。代码为其配备了执行任务所需的工具——配置 MCPToolset 连接到运行在 localhost:8000 的独立服务器，即前面示例中的 FastMCP 服务器。智能体被授权使用该服务器上的 greet 问候工具。这段代码搭建了系统的客户端部分，创建了一个明确任务目标并知晓所需外部工具的智能体。
需要在 fastmcp_client_agent 目录下创建一个 init.py 文件，以确保 ADK 能将智能体识别为可发现的 Python 包。
具体操作步骤：首先打开新终端窗口，运行 python fastmcp_server.py 启动 FastMCP 服务器。然后在终端中进入 fastmcp_client_agent 的上级目录（例如 adk_agent_samples），执行 adk web 命令。待浏览器显示 ADK Web 界面后，从智能体菜单中选择 fastmcp_greeter_agent。此时可输入「问候 John Doe」这样的指令进行测试，智能体将调用 FastMCP 服务器上的 greet 工具生成响应。
要点速览
问题所在： 要让大语言模型真正成为有效的智能体，它们不能只停留在文本生成层面，还需要具备与外部环境交互的能力，既能获取实时数据，又能调用外部软件。如果没有统一的通信标准，每次把大语言模型和外部工具或数据源对接都要从头定制开发，既复杂又难以复用。这种临时凑合的做法严重限制了系统的扩展性，也让构建复杂互联的 AI 系统变得异常困难和低效。
解决之道： 模型上下文协议（MCP）提供了一个标准化的解决方案，它就像是大语言模型和外部系统之间的通用接口。这个开放的标准化协议明确定义了如何发现和使用外部能力。MCP 采用「客户端 - 服务器」架构，让服务器能够向所有兼容的客户端提供工具、数据资源和交互提示。由大语言模型驱动的应用作为客户端，可以按需发现并使用这些资源，整个过程都是可预测的。这种标准化方式促成了一个可互操作、可复用组件的生态系统，大大简化了复杂智能体工作流的开发难度。
经验法则： 当你需要构建复杂、可扩展的企业级智能体系统，而且这些系统要和各种各样的外部工具、数据源、API 打交道时，就应该考虑使用 MCP 协议。特别是在不同大语言模型和工具之间的互操作性很重要，或者智能体需要动态发现新功能而不用重新部署的情况下，MCP 是最佳选择。但如果你的应用比较简单，只需要调用有限几个固定功能，那直接用工具函数调用可能就够用了。
可视化总结
图 1： 模型上下文协议
核心要点
以下是核心要点：
模型上下文协议（MCP）是一个开放标准，它为大语言模型和外部应用、数据源、工具之间的通信提供了统一的规范。
这个协议采用「客户端 - 服务器」架构，明确定义了如何对外提供和使用各种资源、提示模板和工具。
智能体开发套件（ADK）既支持连接现有的 MCP 服务器，也支持把 ADK 里的工具通过 MCP 服务器对外提供。
FastMCP 这个框架让 MCP 服务器的开发和管理变得更简单，特别适合把用 Python 写的工具封装成服务。
通过媒体生成服务 MCP 工具，智能体可以很方便地调用 Google Cloud 的各种生成式媒体能力，比如 Imagen、Veo、Chirp 3 HD 和 Lyria。
MCP 让大语言模型和智能体不再局限于文本生成，而是能够真正与现实世界系统交互，获取动态信息，执行具体操作。
结语
模型上下文协议（MCP）是一个开放标准，它为大语言模型和外部系统之间的通信提供了一套通用规范。这个协议采用「客户端 - 服务器」架构，使 LLM 能够通过标准化工具访问资源、利用提示词并执行操作。MCP 允许 LLM 与数据库交互、管理生成式媒体工作流、控制物联网设备以及自动化金融服务。实际示例演示了设置智能体与 MCP 服务器通信，包括文件系统服务器和使用 FastMCP 构建的服务器，说明了其与智能体开发套件（ADK）的集成。MCP 是开发扩展到基本语言能力之外的交互式 AI 智能体的关键组件。
参考文献
模型上下文协议（MCP）文档（最新版本）。https://google.github.io/adk-docs/mcp/
FastMCP 文档。https://github.com/jlowin/fastmcp
媒体生成服务 MCP 工具。https://google.github.io/adk-docs/mcp/#mcp-servers-for-google-cloud-genmedia
数据库 MCP 工具文档。（最新版本）https://google.github.io/adk-docs/mcp/databases/