MCP 服务器是通过标准化协议接口向 AI 应用程序公开特定功能的程序。每个服务器为特定领域提供专注的功能。 常见示例包括用于文档管理的文件系统服务器、用于消息处理的电子邮件服务器、用于行程规划的旅行服务器以及用于数据查询的数据库服务器。每个服务器都为 AI 应用程序带来了特定领域的功能。

​
核心构建块

服务器通过三个构建块提供功能
构建块目的由谁控制真实世界示例
工具用于 AI 操作模型控制搜索航班、发送消息、创建日历事件
资源用于上下文数据应用程序控制文档、日历、电子邮件、天气数据
提示用于交互模板用户控制“规划一次度假”、“总结我的会议”、“起草一封邮件”

​
工具 - AI 操作

工具使 AI 模型能够通过服务器实现的功能执行操作。每个工具定义一个具有类型化输入和输出的特定操作。模型根据上下文请求执行工具。

​
概述

工具是 LLM 可以调用的、由模式（schema）定义的接口。MCP 使用 JSON Schema 进行验证。每个工具执行单个操作，具有明确定义的输入和输出。最重要的是，工具的执行需要明确的用户批准，确保用户对模型执行的操作保持控制。 协议操作：
方法目的返回
tools/list发现可用的工具包含模式的工具定义数组
tools/call执行一个特定的工具工具执行结果
工具定义示例 
{
  name: "searchFlights",
  description: "Search for available flights",
  inputSchema: {
    type: "object",
    properties: {
      origin: { type: "string", description: "Departure city" },
      destination: { type: "string", description: "Arrival city" },
      date: { type: "string", format: "date", description: "Travel date" }
    },
    required: ["origin", "destination", "date"]
  }
}

​
示例：执行操作

工具使 AI 应用程序能够代表用户执行操作。在旅行规划场景中，AI 应用程序可能会使用多个工具来帮助预订假期。 首先，它使用
searchFlights(origin: "NYC", destination: "Barcelona", date: "2024-06-15")
searchFlights 查询多家航空公司并返回结构化的航班选项。选择航班后，它会使用 
createCalendarEvent(title: "Barcelona Trip", startDate: "2024-06-15", endDate: "2024-06-22")
创建一个日历事件来标记旅行日期。最后，它使用 
sendEmail(to: "[email protected]", subject: "Out of Office", 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 应用程序可以传递日历数据、天气数据和旅行偏好，以便模型可以检查可用性、查询天气模式并参考旅行偏好。 资源模板示例：
{
  "uriTemplate": "weather://forecast/{city}/{date}",
  "name": "weather-forecast",
  "title": "Weather Forecast",
  "description": "Get weather forecast for any city and date",
  "mimeType": "application/json"
}

{
  "uriTemplate": "travel://flights/{origin}/{destination}",
  "name": "flight-search",
  "title": "Flight Search",
  "description": "Search available flights between cities",
  "mimeType": "application/json"
}
这些模板支持灵活的查询。对于天气数据，用户可以访问任何城市/日期组合的预报。对于航班，他们可以搜索任意两个机场之间的航线。当用户输入“NYC”作为出发地机场并开始输入“Bar”作为目的地机场时，系统可以建议“Barcelona (BCN)”或“Barbados (BGI)”。

​
参数补全

动态资源支持参数补全。例如
  • 为 weather://forecast/{city} 输入“Par”可能会建议“Paris”或“Park City”
  • 系统帮助发现有效值，而无需了解确切的格式

​
用户交互模型

资源由应用程序驱动，使主机在如何检索、处理和呈现可用上下文方面具有灵活性。常见的交互模式包括用于在熟悉的文件夹式结构中浏览资源的树状或列表视图、用于查找特定资源的搜索和筛选界面、基于启发式或 AI 选择的自动上下文包含，以及手动选择界面。 应用程序可以自由地通过任何适合其需求的界面模式来实现资源发现。该协议不强制要求特定的 UI 模式，允许使用带有预览功能的资源选择器、基于当前对话上下文的智能建议、用于包含多个资源的批量选择，或与现有文件浏览器和数据浏览器的集成。

​
提示 - 交互模板

提示提供可重用的模板。它们允许 MCP 服务器作者为某个领域提供参数化的提示，或展示如何最好地使用 MCP 服务器。

​
概述

提示是定义了预期输入和交互模式的结构化模板。它们由用户控制，需要显式调用而不是自动触发。提示可以是上下文感知的，引用可用的资源和工具以创建全面的工作流。与资源一样，提示支持参数补全，以帮助用户发现有效的参数值。 协议操作：
方法目的返回
prompts/list发现可用的提示提示描述符数组
prompts/get检索提示详情包含参数的完整提示定义

​
示例：简化的工作流

提示为常见任务提供结构化模板。在旅行规划的上下文中： “规划一次度假”提示：
{
  "name": "plan-vacation",
  "title": "Plan a vacation",
  "description": "Guide through vacation planning process",
  "arguments": [
    { "name": "destination", "type": "string", "required": true },
    { "name": "duration", "type": "number", "description": "days" },
    { "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. 用户调用带参数的提示 
    {
  "prompt": "plan-vacation",
  "arguments": {
    "destination": "Barcelona",
    "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 接着请求用户批准以执行一系列协调的操作：搜索从纽约到巴塞罗那的航班，寻找在指定预算内的酒店，为旅行期间创建日历事件，并发送包含行程详情的确认邮件。