> ## Documentation Index > Fetch the complete documentation index at: https://mcp.transdocs.org/llms.txt > Use this file to discover all available pages before exploring further. # 服务器概念 > 理解 MCP 服务器概念 MCP 服务器是通过标准化协议接口向 AI 应用程序提供特定功能的程序。每个服务器都为特定领域提供专注的功能。 常见的示例包括用于文档管理的文件系统服务器、用于消息处理的电子邮件服务器、用于行程规划的旅行服务器，以及用于数据查询的数据库服务器。每个服务器都为 AI 应用程序带来特定领域的功能。 ## 核心构建模块 服务器通过三个构建模块提供功能： | 构建模块 | 目的 | 控制方 | 真实世界示例 | | ------ | -------- | ------ | ---------------------------- | | **工具** | 用于 AI 操作 | 模型控制 | 搜索航班、发送消息、创建日历事件 | | **资源** | 用于上下文数据 | 应用程序控制 | 文档、日历、电子邮件、天气数据 | | **提示** | 用于交互模板 | 用户控制 | "规划一次假期"、"总结我的会议"、"草拟一封电子邮件" | ### 工具 - AI 操作 工具使 AI 模型能够通过服务器实现的函数执行操作。每个工具定义了具有类型化输入和输出的特定操作。模型根据上下文请求执行工具。 #### 概述 工具是 LLM 可调用的模式定义接口。MCP 使用 JSON Schema 进行验证。每个工具执行一个具有明确定义输入和输出的单一操作。最重要的是，工具执行需要用户的显式批准，确保用户始终对模型执行的操作保持控制。 **协议操作：** | 方法 | 目的 | 返回值 | | ------------ | ------ | ----------- | | `tools/list` | 发现可用工具 | 包含模式的工具定义数组 | | `tools/call` | 执行特定工具 | 工具执行结果 | **示例工具定义：** ```typescript theme={null} { name: "searchFlights", description: "搜索可用航班", inputSchema: { type: "object", properties: { origin: { type: "string", description: "出发城市" }, destination: { type: "string", description: "到达城市" }, date: { type: "string", format: "date", description: "旅行日期" } }, required: ["origin", "destination", "date"] } } ``` #### 示例：执行操作 工具使 AI 应用程序能够代表用户执行操作。在旅行规划场景中，AI 应用程序可能使用多个工具来帮助预订假期。 首先，它使用以下命令搜索航班： ``` searchFlights(origin: "NYC", destination: "Barcelona", date: "2024-06-15") ``` `searchFlights` 查询多家航空公司并返回结构化的航班选项。一旦选择航班，它将使用以下命令创建日历事件： ``` createCalendarEvent(title: "巴塞罗那之旅", startDate: "2024-06-15", endDate: "2024-06-22") ``` 以标记旅行日期。最后，它使用以下命令发送外出通知： ``` sendEmail(to: "team@work.com", subject: "外出通知", body: "...") ``` 以告知同事缺席情况。 每次工具执行都需要用户的显式批准，以确保对执行的操作完全控制。 #### 用户交互模型 工具由模型控制，意味着 AI 模型可以自动发现并调用它们。然而，MCP 通过多种机制强调人工监督。应用程序应在 UI 中清晰显示可用工具，并在考虑或使用工具时提供视觉指示。在任何工具执行之前，必须向用户提供明确的批准对话框，说明工具将执行的操作。 为了信任和安全，应用程序通常强制手动批准，以赋予人类拒绝工具调用的能力。应用程序通常通过批准对话框、预批准某些安全操作的权限设置，以及显示所有工具执行及其结果的活动日志来实现这一点。 ### 资源 - 上下文数据 资源提供对主机应用程序可以检索并提供给 AI 模型作为上下文的信息的结构化访问。 #### 概述 资源从文件、API、数据库或任何其他 AI 需要理解上下文的数据源暴露数据。应用程序可以直接访问这些信息，并决定如何使用它——无论是选择相关部分、使用嵌入进行搜索，还是将所有信息传递给模型。 资源使用基于 URI 的标识，每个资源都有一个唯一的 URI，例如 `file:///path/to/document.md`。它们声明 MIME 类型以进行适当的内容处理，并支持两种发现模式：**直接资源**（具有固定 URI）和 **资源模板**（具有参数化 URI）。 **资源模板** 通过 URI 模板启用动态资源访问。像 `travel://activities/{city}/{category}` 这样的模板可以通过替换 `{city}` 和 `{category}` 参数来访问过滤后的活动数据。例如，`travel://activities/barcelona/museums` 将返回巴塞罗那的所有博物馆。资源模板包括标题、描述和预期 MIME 类型等元数据，使其可发现且自描述。 **协议操作：** | 方法 | 目的 | 返回值 | | -------------------------- | --------- | ---------- | | `resources/list` | 列出可用的直接资源 | 资源描述符数组 | | `resources/templates/list` | 发现资源模板 | 资源模板定义数组 | | `resources/read` | 检索资源内容 | 包含元数据的资源数据 | | `resources/subscribe` | 监控资源更改 | 订阅确认 | #### 示例：访问上下文数据 继续旅行规划示例，资源为 AI 应用程序提供对相关信息的访问权限： * **日历数据** (`calendar://events/2024`) - 检查可用性 * **旅行文档** (`file:///Documents/Travel/passport.pdf`) - 获取重要信息 * **以往行程** (`trips://history/barcelona-2023`) - 用户选择要遵循的以往旅行风格 无需手动复制这些信息，资源为 AI 应用程序提供原始信息。应用程序可以选择如何最好地处理数据。应用程序可能会选择数据子集，使用嵌入或关键词搜索，或将资源的原始数据直接传递给模型。在我们的示例中，在规划阶段，AI 应用程序可以传递日历数据、天气数据和旅行偏好，以便模型可以检查可用性、查找天气模式并参考旅行偏好。 **资源模板示例：** ```json theme={null} { "uriTemplate": "weather://forecast/{city}/{date}", "name": "weather-forecast", "title": "天气预报", "description": "获取任何城市和日期的天气预报", "mimeType": "application/json" } { "uriTemplate": "travel://flights/{origin}/{destination}", "name": "flight-search", "title": "航班搜索", "description": "在城市之间搜索可用航班", "mimeType": "application/json" } ``` 这些模板支持灵活的查询。对于天气数据，用户可以访问任何城市/日期组合的预报。对于航班，他们可以在任何两个机场之间搜索航班。当用户输入 "NYC" 作为 `origin` 机场，并开始输入 "Bar" 作为 `destination` 机场时，系统可以建议 "Barcelona (BCN)" 或 "Barbados (BGI)"。 #### 参数补全 动态资源支持参数补全。例如： * 输入 "Par" 作为 `weather://forecast/{city}` 的输入可能会建议 "Paris" 或 "Park City" * 系统帮助发现有效值，而无需确切格式知识 #### 用户交互模型 资源由应用程序驱动，为主机提供了检索、处理和呈现可用上下文的灵活性。常见的交互模式包括用于浏览资源的树或列表视图（类似于熟悉的文件夹结构）、用于查找特定资源的搜索和过滤界面、基于启发式或 AI 选择的自动上下文包含，以及手动选择界面。 应用程序可以自由地通过任何适合其需求的界面模式实现资源发现。该协议不规定特定的 UI 模式，允许使用带有预览功能的资源选择器、基于当前对话上下文的智能建议、用于包含多个资源的批量选择，或与现有文件浏览器和数据浏览器的集成。 ### 提示 - 交互模板 提示提供可重用的模板。它们允许 MCP 服务器作者为一个领域提供参数化提示，或展示如何最佳使用 MCP 服务器。 #### 概述 提示是定义预期输入和交互模式的结构化模板。它们由用户控制，需要显式调用，而不是自动触发。提示可以是上下文感知的，引用可用的资源和工具以创建全面的工作流程。与资源一样，提示支持参数补全，以帮助用户发现有效的参数值。 **协议操作：** | 方法 | 目的 | 返回值 | | -------------- | -------- | ----------- | | `prompts/list` | 发现可用提示 | 提示描述符数组 | | `prompts/get` | 检索提示详细信息 | 包含参数的完整提示定义 | #### 示例：简化的工作流程 提示为常见任务提供结构化模板。在旅行规划上下文中： **"规划一次假期" 提示：** ```json theme={null} { "name": "plan-vacation", "title": "规划一次假期", "description": "指导完成假期规划过程", "arguments": [ { "name": "destination", "type": "string", "required": true }, { "name": "duration", "type": "number", "description": "天数" }, { "name": "budget", "type": "number", "required": false }, { "name": "interests", "type": "array", "items": { "type": "string" } } ] } ``` 无需非结构化的自然语言输入，提示系统支持： 1. 选择 "规划一次假期" 模板 2. 结构化输入：巴塞罗那、7 天、3000 美元、\["海滩", "建筑", "美食"] 3. 基于模板的一致工作流程执行 #### 用户交互模型 提示由用户控制，需要显式调用。应用程序通常通过各种 UI 模式暴露提示，例如斜杠命令（输入 "/" 查看可用提示如 /plan-vacation）、可搜索的命令面板、用于常用提示的专用 UI 按钮，或建议相关提示的上下文菜单。 该协议给予实现者设计符合其应用程序自然界面的自由。关键原则包括轻松发现可用提示、清晰描述每个提示的作用、自然的参数输入和验证，以及透明显示提示的底层模板。 ## 它们如何协同工作 当多个服务器通过统一接口协作时，MCP 的真正力量得以显现，结合它们的专门功能。 ### 示例：多服务器旅行规划 考虑一个具有三个连接服务器的 AI 应用程序： 1. **旅行服务器** - 处理航班、酒店和行程 2. **天气服务器** - 提供气候数据和预报 3. **日历/电子邮件服务器** - 管理日程和通信 #### 完整流程 1. **用户使用参数调用提示：** ```json theme={null} { "prompt": "plan-vacation", "arguments": { "destination": "巴塞罗那", "departure_date": "2024-06-15", "return_date": "2024-06-22", "budget": 3000, "travelers": 2 } } ``` 2. **用户选择要包含的资源：** * `calendar://my-calendar/June-2024`（来自日历服务器） * `travel://preferences/europe`（来自旅行服务器） * `travel://past-trips/Spain-2023`（来自旅行服务器） 3. **AI 处理请求：** AI 首先读取所有选定资源以收集上下文。从日历中，它识别可用日期。从旅行偏好中，它了解首选航空公司和酒店类型。从以往行程中，它发现以前喜欢的地点。从天气数据中，它检查旅行期间的气候条件。 使用这些上下文，AI 然后请求用户批准执行一系列协调操作：搜索从纽约到巴塞罗那的航班，在指定预算内寻找酒店，为整个旅行期间创建日历事件，并发送包含旅行详细信息的确认电子邮件。