模型上下文协议（MCP）简介
Introduction to Model Context Protocol (MCP)
- 了解模型上下文协议是什么以及它为何重要
- 学习与 MCP 相关的关键概念和术语
- 探究 MCP 所解决的集成挑战
- 了解 MCP 的主要优势和目标
- 观看一个 MCP 集成的简单实际示例
模型上下文协议（MCP）的重要性
人工智能生态系统正在迅速发展，大型语言模型（LLMs）和其他人工智能系统的能力日益增强。然而，这些模型往往受限于其训练数据，无法获取实时信息或使用专门的工具。这种局限性阻碍了人工智能系统在许多场景下提供真正相关、准确且有价值的回应的潜力。此时，模型上下文协议（MCP）便发挥了关键作用。MCP使人工智能模型能够与外部数据源、工具和环境相连接，从而实现人工智能系统与更广泛的数字世界之间信息和能力的无缝传输。这种互操作性对于真正有用的人工智能应用的成长和普及至关重要。
关键概念与术语
MCP常被描述为人工智能应用的“USB-C接口”。就像USB-C为连接各种外设到计算设备提供了标准化的物理和逻辑接口一样，MCP也为将人工智能模型与外部能力连接起来提供了一个一致的协议。这种标准化对整个生态系统都有益处：
- 用户可以在不同的人工智能应用中享受更简单、更一致的使用体验；
- 人工智能应用开发者可以轻松地与不断增长的工具和数据源生态系统进行集成；
- 工具和数据提供商只需创建一个单一的、能与多个人工智能应用协同工作的实现方案；
- 更广泛的生态系统则受益于提高的互操作性、创新以及减少的碎片化现象。
集成问题
M×N 集成问题指的是在没有标准化方法的情况下，将 M 个不同的人工智能应用连接到 N 个不同的外部工具或数据源所面临的挑战。
无 MCP 的情况（M×N 问题）
如果没有像 MCP 这样的协议，开发者需要为每一种人工智能应用与外部能力的可能组合创建 M×N 个定制集成方案。也就是说，对于每一种人工智能应用，都需要针对每一个外部工具或数据源开发专门的集成接口。随着人工智能应用数量（M）和外部工具或数据源数量（N）的增加，这种定制集成的工作量会呈指数级增长，导致开发成本高昂、效率低下，且难以维护和扩展。
使用 MCP 后（M+N 解决方案）
MCP 通过提供一个标准接口，将原本的 M×N 问题转变为 M+N 问题：每个人工智能应用只需实现一次 MCP 的客户端部分，每个工具/数据源也只需实现一次 MCP 的服务器端部分。这极大地降低了集成的复杂性和维护负担。
具体来说，在没有 MCP 之前，开发者要为 M 个应用与 N 个工具/数据源的每一种组合都开发集成代码，总共有 M×N 种集成情况需要处理。而有了 MCP 之后，应用开发者只需要专注于实现与 MCP 客户端相关的代码，就可以与所有支持 MCP 服务器端的工具/数据源进行交互；同样，工具/数据源提供者只需要实现一次 MCP 服务器端代码，就能被所有支持 MCP 客户端的人工智能应用所调用。这样，原本需要处理的大量定制集成工作，就简化为只需要处理 M 个应用客户端实现和 N 个工具/数据源服务器端实现，大大减少了开发、测试和维护的工作量，也降低了出错的可能性，提高了整个系统的可扩展性和稳定性。
核心 MCP 术语
Components（组件）
- Host（主机）：这是最终用户直接交互的用户端人工智能应用。例如，Anthropic 的 Claude Desktop、像 Cursor 这类由人工智能增强的集成开发环境（IDE）、像 Hugging Face Python SDK 这样的推理库，或者使用 LangChain 或 smolagents 等库构建的自定义应用。主机发起与 MCP 服务器的连接，并协调用户请求、大型语言模型（LLM）处理以及外部工具之间的整体流程。
- MCP Client（MCP 客户端）：MCP 客户端是嵌入在人工智能应用中的组件，负责按照 MCP 协议与外部工具或数据源进行通信。它就像是一个“请求发起者”，知道如何向 MCP 服务器端发送请求，并处理从服务器端接收到的响应。将人工智能应用内部的需求（例如获取特定数据、调用特定工具功能）按照 MCP 协议的格式进行封装，然后发送给合适的 MCP 服务器端。同时，它能够解析服务器端返回的结果，并将其转换回人工智能应用可以理解和使用的格式。
- MCP Server（MCP 服务器端）：MCP 服务器端是部署在外部工具或数据源处的组件，用于接收来自 MCP 客户端的请求，执行相应的操作，并将结果返回给客户端。它充当着“服务提供者”的角色，按照 MCP 协议的标准来处理各种请求。监听来自 MCP 客户端的请求，根据请求中的信息确定需要执行的具体操作（例如查询数据库、调用特定算法），完成操作后将结果按照 MCP 协议规定的格式返回给客户端。
Capability（能力）
在 MCP 语境中，能力指的是外部工具或数据源所具备的特定功能或服务。例如，一个图像识别工具的能力可能是识别图像中的物体；一个天气数据源的能力可能是提供特定地区的实时天气信息。明确外部工具或数据源能够为人工智能应用提供哪些具体的功能。MCP 协议通过定义能力，使得人工智能应用可以清晰地了解可用的外部资源，并能够有针对性地发起请求。
| 能力 | 描述 | 示例 |
|---|---|---|
| Tools（工具） | 人工智能模型可调用的可执行函数，用于执行操作或检索计算数据。通常与应用的使用场景相关。 | 一个天气应用程序的工具可能是一个返回特定地点天气的函数。 |
| Resources（资源） | 只读数据源，提供上下文信息而无需大量计算。 | 一个研究人员助手可能拥有一个科学论文的资源。 |
| Prompts（提示） | 预定义的模板或工作流程，用于引导用户、人工智能模型和可用能力之间的交互。 | 一个总结提示。 |
| Sampling（采样） | 服务器发起的请求，要求客户端/主机执行大型语言模型（LLM）交互，从而实现递归操作，即 LLM 可以审查生成的内容并做出进一步决策。 | 一个写作应用程序审查其自身输出，并决定进一步润色它。 |
| 实体（Entity） | 名称（Name） | 描述（Description） |
|---|---|---|
| 工具（Tool） | 代码解释器（Code Interpreter） | 一种能够执行大型语言模型（LLM）所编写代码的工具。 |
| 资源（Resource） | 文档（Documentation） | 包含应用程序文档的资源。 |
| 提示（Prompt） | 代码风格（Code Style） | 引导大型语言模型生成代码的提示。 |
| 采样（Sampling） | 代码审查（Code Review） | 一种允许大型语言模型审查代码并做出进一步决策的采样方式。 |
MCP 的架构组件
主机（Host）、客户端（Client）和服务器端（Server）
模型上下文协议（MCP）构建在客户端 - 服务器端架构之上，该架构可实现人工智能模型与外部系统之间的结构化通信。
MCP 架构由三个主要组件构成，每个组件都有明确的角色和职责：主机（Host）、客户端（Client）和服务器端（Server），接下来让我们更深入地探讨每个组件及其职责。
主机（Host）
主机是最终用户直接交互的用户端人工智能应用。
示例包括：
- 像 OpenAI 的 ChatGPT 或 Anthropic 的 Claude Desktop 这类人工智能聊天应用
- 像 Cursor 这类由人工智能增强的集成开发环境（IDE），或是与 Continue.dev 等工具的集成
- 使用 LangChain 或 smolagents 等库构建的自定义人工智能代理和应用
主机的职责包括：
- 管理用户交互和权限
- 通过 MCP 客户端发起与 MCP 服务器的连接
- 协调用户请求、大型语言模型（LLM）处理以及外部工具之间的整体流程
- 以连贯的格式将结果呈现给用户
客户端（Client）
客户端是主机应用中的一个组件，负责管理与特定 MCP 服务器的通信。其主要特点包括：
- 每个客户端与单个服务器保持 1:1 的连接
- 处理 MCP 通信的协议级细节
- 在主机逻辑与外部服务器之间充当中间人
服务器端（Server）
服务器端是一个外部程序或服务，通过 MCP 协议向人工智能模型暴露能力。服务器端：
- 提供对特定外部工具、数据源或服务的访问权限
- 作为现有功能的轻量级封装
- 可以在本地（与主机在同一台机器上）运行，也可以在远程（通过网络）运行
- 以标准化格式暴露其能力，以便客户端能够发现并使用
通信流程（Communication Flow)
用户交互流程
- 用户交互：用户与主机应用进行交互，表达意图或提出查询。
- 主机处理：主机处理用户的输入，可能会使用大型语言模型（LLM）来理解请求，并确定可能需要哪些外部能力。
- 客户端连接：主机指示其客户端组件连接到合适的服务器端。
- 能力发现：客户端查询服务器端，以发现其提供的能力（工具、资源、提示）。
- 能力调用：根据用户的需求或大型语言模型的判断，主机指示客户端从服务器端调用特定的能力。
- 服务器端执行：服务器端执行所请求的功能，并将结果返回给客户端。
- 结果整合：客户端将这些结果传回给主机，主机将这些结果纳入大型语言模型的上下文中，或直接呈现给用户。
这种架构的一个关键优势在于其模块化特性。单个主机可以通过不同的客户端同时连接到多个服务器端。无需对现有主机进行更改，就可以将新的服务器端添加到该生态系统中。不同服务器端提供的能力可以轻松地进行组合使用。该架构看似简单，但其强大之处在于通信协议的标准化以及组件之间职责的清晰划分。这种设计构建了一个具有凝聚力的生态系统，在这个生态系统中，人工智能模型能够无缝连接日益增多的外部工具和数据源。
通信协议
MCP（模型上下文协议）定义了一种标准化的通信协议，使客户端和服务器端能够以一致、可预测的方式交换消息。这种标准化对于整个社区内的互操作性至关重要。
JSON-RPC：基础
MCP（模型上下文协议）的核心在于，它使用 JSON-RPC 2.0 作为客户端与服务器端之间所有通信的消息格式。JSON-RPC 是一种采用 JSON 编码的轻量级远程过程调用协议，这使得它具备以下特点：
- 可读性强，易于调试
- 与编程语言无关，支持在任何编程环境中实现
- 发展成熟，有明确的规范且被广泛采用
该协议定义了三种类型的消息：
请求（Requests）
由客户端发送至服务器端以发起操作。请求消息包含：
- 一个唯一标识符（id）
- 要调用的方法名称（例如，tools/call）
- 该方法的参数（如果有）
{"jsonrpc": "2.0","id": 1,"method": "tools/call","params": {"name": "weather","arguments": {"location": "San Francisco"}}
}
响应（Responses）
由服务器端发送至客户端以回复请求。响应消息包含：
- 与对应请求相同的唯一标识符（id）
- 成功时返回结果（result），失败时返回错误（error）
{"jsonrpc": "2.0","id": 1,"result": {"temperature": 62,"conditions": "Partly cloudy"}
}
{"jsonrpc": "2.0","id": 1,"error": {"code": -32602,"message": "Invalid location parameter"}
}
通知（Notifications）
单向消息，无需回复。通常由服务器端发送至客户端，用于提供事件相关的更新或通知。
{"jsonrpc": "2.0","method": "progress","params": {"message": "Processing data...","percent": 50}
}
传输机制
JSON-RPC 定义了消息格式，但 MCP 还规定了这些消息在客户端与服务器端之间的传输方式。MCP 支持两种主要的传输机制：
标准输入输出（stdio）
stdio 传输机制用于本地通信，即客户端和服务器端在同一台机器上运行：主机应用会启动服务器端作为子进程，并通过向其标准输入（stdin）写入数据以及从其标准输出（stdout）读取数据来与之通信。这种传输机制的主要优势在于其简单易用，无需进行网络配置，并且能够被操作系统安全地隔离（即运行在沙盒环境中）。
HTTP + SSE/HTTP
HTTP+SSE 传输机制用于远程通信，此时客户端和服务器端可能位于不同的机器上：通信通过HTTP协议进行，服务器端使用服务器推送事件（SSE）技术，通过持久连接向客户端推送更新。这种传输机制的主要优势在于，它能够在不同网络间运行，支持与网络服务的集成，并且与无服务器环境兼容。MCP标准最近的更新引入或完善了“可流式传输的HTTP”，它通过允许服务器在需要时动态升级到SSE（服务器推送事件）进行流式传输，同时保持与无服务器环境的兼容性，从而提供了更高的灵活性。
交互生命周期
现在，让我们从MCP协议的角度，来看看客户端（💻）与服务器端（🌐）之间一次完整交互的生命周期。MCP协议定义了客户端与服务器端之间结构化的交互生命周期：
初始化（Initialize）
客户端连接到服务器端，双方交换协议版本和功能信息，服务器端则回应其支持的协议版本和功能信息。
发现（Discovery）
客户端请求获取有关可用功能的信息，服务器端则回应一份可用工具的列表。
执行（Execution）
客户端根据主机的需求调用相应功能。
终止（Termination）
当连接不再需要时，连接会被优雅地关闭，且服务器端会确认关闭请求。
理解 MCP 功能
MCP 服务器端通过通信协议向客户端暴露多种功能。这些功能可分为四大主要类别，每一类都具有独特的特性和使用场景。下面，让我们来探讨这些构成 MCP 功能基础的核心原语（核心基本单元）。
工具（Tools）
工具是人工智能模型可通过 MCP 协议调用的可执行函数或操作。
-
控制：工具通常由模型控制，这意味着人工智能模型（大型语言模型，LLM）会根据用户请求和上下文来决定何时调用这些工具。
-
安全性：由于工具能够执行具有副作用的操作，因此工具的执行可能存在风险。因此，它们通常需要用户明确批准。
-
使用场景：发送消息、创建工单、查询 API、执行计算等。
示例：一个天气工具，用于获取指定位置的当前天气数据：
def get_weather(location: str) -> dict:"""Get the current weather for a specified location."""# Connect to weather API and fetch datareturn {"temperature": 72,"conditions": "Sunny","humidity": 45}
资源（Resources）
资源提供对数据源的只读访问权限，使人工智能模型能够检索上下文信息，而无需执行复杂的逻辑。
-
控制：资源由应用程序控制，这意味着主机应用程序通常会决定何时访问这些资源。
-
特性：它们专为以最小计算量进行数据检索而设计，类似于 REST API 中的 GET 端点。
-
安全性：由于资源是只读的，因此它们通常比工具带来的安全风险更低。
-
使用场景：访问文件内容、检索数据库记录、读取配置信息等。
示例：一个提供文件内容访问权限的资源：
def read_file(file_path: str) -> str:"""Read the contents of a file at the specified path."""with open(file_path, 'r') as f:return f.read()
提示词（Prompts）
提示词是预定义的模板或工作流程，用于引导用户、人工智能模型与服务器端功能之间的交互。
-
控制：提示词由用户控制，通常在主机应用程序的用户界面中以选项形式呈现。
-
目的：它们对交互进行结构化设计，以便最优利用可用的工具和资源。
-
选择：用户通常在人工智能模型开始处理之前选择一个提示词，为交互设定上下文。
-
使用场景：常见工作流程、专项任务模板、引导式交互等。
示例：一个用于生成代码审查的提示词模板：
def code_review(code: str, language: str) -> list:"""Generate a code review for the provided code snippet."""return [{"role": "system","content": f"You are a code reviewer examining {language} code. Provide a detailed review highlighting best practices, potential issues, and suggestions for improvement."},{"role": "user","content": f"Please review this {language} code:\n\n```{language}\n{code}\n```"}]
采样（Sampling）
采样允许服务器端请求客户端（具体来说，是主机应用程序）执行与大型语言模型（LLM）的交互。
-
控制：采样由服务器端发起，但需要客户端/主机提供协助。
-
目的：它支持服务器端驱动的自主代理行为，并可能实现递归或多步骤交互。
-
安全性：与工具类似，采样操作通常需要用户批准。
-
使用场景：复杂的多步骤任务、自主代理工作流程、交互式流程等。
示例：服务器端可能会请求客户端分析其已处理的数据：
def request_sampling(messages, system_prompt=None, include_context="none"):"""Request LLM sampling from the client."""# In a real implementation, this would send a request to the clientreturn {"role": "assistant","content": "Analysis of the provided data..."}
采样流程遵循以下步骤：
- 服务器端发送请求：服务器端向客户端发送一个采样（sampling）/创建消息（createMessage）请求。
- 客户端审查并可能修改请求：客户端收到请求后，会对其进行审查，并有权根据需要修改该请求。
- 客户端从大型语言模型（LLM）采样：审查并（如有必要）修改请求后，客户端会从大型语言模型（LLM）中获取采样结果。
- 客户端审查完成结果：客户端对从大型语言模型（LLM）获得的完成结果进行审查。
- 客户端将结果返回给服务器端：审查完成后，客户端将最终结果返回给服务器端。
这种（human-in-the-loop）的设计确保了用户能够掌控大型语言模型（LLM）所看到的内容以及生成的结果。在实施采样功能时，提供清晰、结构良好的提示词（prompts）并包含相关上下文信息至关重要。
功能如何协同工作
在下表中，我们概述了各项功能、它们的控制方、控制方向以及其他一些细节。
| 功能 | 控制方 | 控制方向 | 是否有副作用 | 是否需要批准 | 典型使用场景 |
|---|---|---|---|---|---|
| 工具 | 模型（大型语言模型，LLM） | 客户端 → 服务器端 | 是（可能） | 是 | 执行操作、调用应用程序编程接口（API）、数据操作 |
| 资源 | 应用程序 | 客户端 → 服务器端 | 否（只读） | 通常不需要 | 数据检索、上下文收集 |
| 提示词 | 用户 | 服务器端 → 客户端 | 否 | 否（由用户选择） | 引导式工作流程、专项模板 |
| 采样 | 服务器端 | 服务器端 → 客户端 → 服务器端 | 间接（有） | 是 | 多步骤任务、自主代理行为 |
这些功能设计上旨在以互补的方式协同工作：
- 用户可能会选择一个提示词（Prompt）来启动一个专项工作流程。
- 该提示词可能会包含来自资源（Resources）的上下文信息。
- 在处理过程中，人工智能模型可能会调用工具（Tools）来执行特定的操作。
- 对于复杂的操作，服务器端可能会使用采样（Sampling）功能来请求额外的大型语言模型（LLM）处理。
发现流程（Discovery Process）
MCP的一个关键特性是动态能力发现。当客户端连接到服务器端时，它可以通过特定的列表方法来查询可用的工具（Tools）、资源（Resources）和提示词（Prompts）：
- tools/list：发现可用的工具（Tools）
- resources/list：发现可用的资源（Resources）
- prompts/list：发现可用的提示词（Prompts）
MCP软件开发工具包（MCP SDK）
模型上下文协议（Model Context Protocol）为JavaScript、Python及其他语言提供了官方软件开发工具包（SDK）。这使得在你的应用程序中轻松实现MCP客户端和服务器端成为可能。这些SDK处理底层协议细节，让你能够专注于构建应用程序的功能。
SDK概述
SDK都提供了类似的核心功能，遵循我们之前讨论的MCP协议规范。它们负责处理：
- 协议级通信：处理客户端与服务器端之间的底层通信。
- 能力注册与发现：允许注册其能力，并发现对方的能力。
- 消息序列化/反序列化：将消息转换为适合传输的格式，并在接收端将其转换回原始格式。
- 连接管理：建立、维护和关闭客户端与服务器端之间的连接。
- 错误处理：检测并处理通信过程中可能出现的错误。
核心原语实现
Tools, Resources, Prompts
from mcp.server.fastmcp import FastMCP# Create an MCP server
mcp = FastMCP("Weather Service")# Tool implementation
@mcp.tool()
def get_weather(location: str) -> str:"""Get the current weather for a specified location."""return f"Weather in {location}: Sunny, 72°F"# Resource implementation
@mcp.resource("weather://{location}")
def weather_resource(location: str) -> str:"""Provide weather data as a resource."""return f"Weather data for {location}: Sunny, 72°F"# Prompt implementation
@mcp.prompt()
def weather_report(location: str) -> str:"""Create a weather report prompt."""return f"""You are a weather reporter. Weather report for {location}?"""# Run the server
if __name__ == "__main__":mcp.run()
# running
mcp dev server.py
MCP SDKs
MCP（模型上下文协议）的设计旨在不依赖于特定编程语言，并且为几种流行的编程语言提供了官方软件开发工具包（SDK）：
| Language | Repository | Maintainer(s) | Status |
|---|---|---|---|
| TypeScript | github.com/modelcontextprotocol/typescript-sdk | Anthropic | Active |
| Python | github.com/modelcontextprotocol/python-sdk | Anthropic | Active |
| Java | github.com/modelcontextprotocol/java-sdk | Spring AI (VMware) | Active |
| Kotlin | github.com/modelcontextprotocol/kotlin-sdk | JetBrains | Active |
| C# | github.com/modelcontextprotocol/csharp-sdk | Microsoft | Active (Preview) |
| Swift | github.com/modelcontextprotocol/swift-sdk | loopwork-ai | Active |
| Rust | github.com/modelcontextprotocol/rust-sdk | Anthropic/Community | Active |
| Dart | https://github.com/leehack/mcp_dart | Flutter Community | Active |
MCP 客户端
理解 MCP 客户端
MCP 客户端是至关重要的组件，它们充当着人工智能应用程序（主机，Hosts）与 MCP 服务器所提供的外部功能之间的桥梁，负责处理与 MCP Server的通信。
- 用户界面客户端
- 聊天界面客户端
- 交互式开发客户端
配置 MCP 客户端
既然我们已经介绍了 MCP 协议的核心内容，接下来让我们看看如何配置你的 MCP 服务器和客户端。要实现 MCP 服务器和客户端的有效部署，正确的配置是必不可少的。
MCP 配置文件
MCP 主机使用配置文件来管理服务器连接。这些文件定义了哪些服务器可用以及如何连接到它们。
幸运的是，这些配置文件非常简单易懂，并且在主要的 MCP 主机中保持一致。
MCP 的标准配置文件名为 mcp.json。以下是其基本结构：
{"servers": [{"name": "Server Name","transport": {"type": "stdio|sse",// Transport-specific configuration}}]
}
使用 stdio 传输方式的配置：对于使用 stdio 传输方式的本地服务器，配置文件需要包括启动服务器进程的命令和参数。这种配置方式通常用于本地开发或测试场景，其中服务器和客户端在同一台机器上运行，并通过标准输入输出（stdio）进行通信。
{"servers": [{"name": "File Explorer","transport": {"type": "stdio","command": "python","args": ["/path/to/file_explorer_server.py"] // This is an example, we'll use a real server in the next unit}}]
}
HTTP SSE 传输的配置：对于使用 HTTP SSE 传输的远程服务器，配置包括服务器 URL。
{"servers": [{"name": "Remote API Server","transport": {"type": "sse","url": "https://example.com/mcp-server"}}]
}
配置中的环境变量：可以使用 env 字段将环境变量传递给服务器进程。以下是在服务器代码中访问这些环境变量的方法：
import os# Access environment variables
github_token = os.environ.get("GITHUB_TOKEN")
if not github_token:raise ValueError("GITHUB_TOKEN environment variable is required")# Use the token in your server code
def make_github_request():headers = {"Authorization": f"Bearer {github_token}"}# ... rest of your code
mcp.json 中相应的配置如下所示：
{"servers": [{"name": "GitHub API","transport": {"type": "stdio","command": "python","args": ["/path/to/github_server.py"], // This is an example, we'll use a real server in the next unit"env": {"GITHUB_TOKEN": "your_github_token"}}}]
}
微型代理客户端（Tiny Agents Clients）
微型代理提供了一种简单的方式来创建人工智能代理，这些代理能够使用 MCP 服务器提供的工具。微型代理可以在命令行环境中运行 MCP 服务器。要做到这一点，我们需要安装 npm，并使用 npx 来运行服务器。无论是对于 Python 还是 JavaScript，我们都需要这些工具。
# install npx
npm install -g npx
然后，需要安装具有 MCP 支持的 huggingface_hub 包。这将允许我们运行 MCP 服务器和客户端。
pip install "huggingface_hub[mcp]>=0.32.0"
需要登录hugging face hub才能访问MCP server。
huggingface-cli login
连接到 MCP 服务器
创建一个agent 配置文件：agent.json
{"model": "Qwen/Qwen2.5-72B-Instruct","provider": "nebius","servers": [{"type": "stdio","config": {"command": "npx","args": ["@playwright/mcp@latest"]}}]
}
在这个配置中，我们使用的是 @playwright/mcp MCP 服务器。这是一个可以通过 Playwright 控制浏览器的 MCP 服务器。
安装运行Tiny-agent:
npm install @huggingface/tiny-agents
tiny-agents run agent.json
或者：./my-agent/agent.json
npx @huggingface/tiny-agents run ./my-agent
该代理配置为通过 Nebius 推理提供者使用 Qwen/Qwen2.5-72B-Instruct 模型，并配备了一个剧作家 MCP 服务器，允许它使用网络浏览器！代理配置被加载，从指定其在 tiny-agents/tiny-agents Hugging Face 上的路径。当你运行代理时，你将看到它加载，列出它从连接的 MCP 服务器发现的工具。