MCP 协议：AI 应用连接外部系统的标准化接口

🕒 2025-11-11 📁 Ai应用 👤 laumy 🔥 35 热度

简介

什么是MCP

MCP是Model Context Protocol模型上下文的一个开源标准，用于连接人工智能应用程序到外部系统。使用MCP，让Claude、ChatGPT这样的AI application可以连接到数据源（例如本地文件、数据库）、工具（例如搜索引擎、计算器）和工作流（例如专业提示），从而能够访问关键信息并执行任务。

可以把MCP类比是AI application的USB-C接口，USB-C为电子设备提供了一种标准化的连接方式，MCP也为Ai application连接到外部系统提供了一种标准化的方式。

具体MCP能够实现什么了？

Agents可以访问Google日历和Notion，充当更个性化的AI助手。
Claude code可以使用Figma设计生成整个网络应用程序。
企业聊天机器人可以连接到组织内部的多个数据库，使用户能够通过聊天分析数据。
AI模型可以在Blendoer中创建3D设计，并使用3D打印机将其打印出来。

MCP为什么重要？

根据生态系统的位置不同，MCP可以带来一些列的好处。

开发者：MCP在构建或集成AI应用程序或代理是，可以减少开发时间和复杂性。
AI应用或智能体：MCP提供对数据源、工具和应用程序系统的访问，这将增强能力并改善最终用户体验。
最终用户：MCP导致更强大的AI应用或智能体，它们可以访问您的数据并在必要时代表您采取行动。

MCP架构

模型上下文包括以下项目：

MCP 规范：概述客户端和服务器实现要求的MCP规范。
MCP SDKs：实现MCP不同的编程语言SDK。
MCP开发工具：用于开发MCP服务器和客户端的工具。
MCP参考服务器实现：MCP服务端的参考代码。

MCP的概念

Participants参与者

MCP遵循客户端-服务端架构，其中MCP Host（如Claude Code或Claude Desktop等AI应用）建立与一个或多个MCP服务器的链接。MCP Host通过为每个MCP server创建一个MCP Client来实现这一点。每个MCP Client与其对一个的MCP Server保持一对一的专用连接。

在MCP架构中，关键参与者可以分为如下：

MCP Host：协调和管理一个或多个MCP Client的AI应用。
MCP Client：一个维护与MCP Server连接的组件，并从MCP 服务器获取上下文供MCP主机使用。
MCP Server：一个想MCP 客户端提供上下文的程序。

下面来举个例子，Visual studio Code作为MCP Host。当Visual Studio Code与MCP Server建立连接时，Visual Studio Code运行时会实例化一个MCP Client对象，该对象维护与Sentry MCP服务的连接。当Visual Studio Code随后连接到另一个MCP Server时，Visual Studio Code运行时会实例化另一个MCP Client对象以维护此连接，从而保持MCP客户端与MCP服务器的一对一关系。

需要注意的是，MCP server指的是提供上下文数据的程序，无论他运行在哪里。MCP服务器可以子啊本地或远程运行。例如，当Claude桌面启动文件系统服务器时，服务器在同一个机器上本地运行，因为他使用STDIO传输。这通常被成为本地MCP server，而官方Sentry MCP服务器在Sentry平台运行，并使用Streamable HTTP传输，这通常被称为远程MCP服务器。

MCP的层次

MCP有两层组成：

data layer：定义JSION-RPC的客户端-服务端通信协议，包括生命周期管理，以及核心原语，如工具、资源、提示和通知。
transport layer：定义使客户端和服务器之间能够进行数据交换的通信机制和通道，包括特定于传输的连接建立、信息帧和授权。

从概念上将，数据层是内层，而传输层是外层。

Data layer

数据层实现了一个基于JSON-RPC 2.0的交互协议，该协议定义了消息结构和语义。该层包括。

Lifecycle management：处理客户端和服务器之间的连接初始化、能力协商和连接终止。
Server features：使服务器能够提供核心功能，包括用于AI操作的工具、用于上下文数据的资源以及从客户端接收和发送交互。
Client features：使服务器能够请求客户端从主机LLM采样、从用户获取输入以及向客户端记录消息。
Utility features：支持实时更新通知和长时间运行操作的进度跟踪等附加功能。

Transport layer

传输层管理客户端和服务器之间的通信通道和身份验证，它处理连接建立、消息帧处理以及MCP参与之间的安全通信。

MCP 支持两种传输机制：

stdio transport：使用标准输入/输出流，在本地同一台机器上的进程之间进行直接进程通信，提供最佳性能且无网络开销。
Streamable HTTP transport: 使用HTTP POST传输客户端到服务器的消息，并可选的使用服务器发送事件（Server-Sent Events）实现流式传输功能。这种传输方式支持远程服务器通信，并支持标准HTTP认证方法，包括令牌、API密钥和自定义头信息。

传输层将通信细节抽象化，与协议层分离，使得 JSON-RPC 2.0 消息格式在所有传输机制中保持一致。

Data Layer Protocol

MCP的核心部分之一是定义MCP client与MCP server之间的模式和语义。开发者可以会发现数据层特别是基本数据类型集合，这是MCP中最有趣的部分。他是定义开发者如何从MCP服务器共享上下文到MCP客户端的部分。

MCP 使用JSION-RPC 2.0作为其底层的RPC协议，客户端和服务器相互发送请求并做出相应的会议，当无需响应时，可以使用通知。

MCP定义了服务器可以公开的3个核心基本概念：

Tools：AI应用程序可以调用执行操作的可执行函数（例如，文件操作、API调用、数据库查询）
Rresources：为AI应用程序提供上下文信息的数据源（例如，文件内容、数据库记录、API响应）
Prompts：可重复使用的模版，有助于构建与语言模型交互（例如系统提示、少量样本示例）

每种原始类型都有与之关联的发现方法（/list）、检索方法（/get），在某些情况下还有执行方法（tools/call）。在MCP客户端将使用*/list方法发现可用的原始类型。例如，客户端可以先列出所有可用的工具（tools/list），然后执行他们。

MCP还定义了客户端可以公开的原语，这些原语允许MCP服务器构建更丰富的交互。

Sampling：采样，允许server从client的ai应用程序请求语音模型补全，当server希望访问语言模型，但希望保持模型独立且不在其MCP server中包含语音模型SDK时，这很有用。他们可以使用sampling/comlete方法从客户端的AI应用程序请求语音模型补全。
Elicitation：提取，允许server从用户哪里请求额外信息，当server希望从用户获取更多信息，或请求确认某个操作时，这很有用，使用elicitation/request方法从用户哪里请求额外信息。
logging：日志记录，允许server向client发送日志信息，用于调试和监控目的。

Notifications该协议支持实时通知，以实现server与client之间的动态更新，例如，当server可用工具发生变化是，比如新功能可用或现有工具被修改，服务器可以向连接的客户端发送工具更新通知，告知这些变化，通知以JSON-RPC 2.0通知消息的形式发送，并使用MCP server能够向连接的client提供实时更新。

协议交互Example

初始化（生命周期管理）

MCP通过能力协商握手开始生命周期管理，如生命周期管理部分所述，客户端发送initialize请求以建立连接并协商支持的功能。

initialize request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "elicitation": {}
    },
    "clientInfo": {
      "name": "example-client",
      "version": "1.0.0"
    }
  }
}

initialize response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {
        "listChanged": true
      },
      "resources": {}
    },
    "serverInfo": {
      "name": "example-server",
      "version": "1.0.0"
    }
  }
}

这段是典型的JSON-RPC协议交互过程，用于客户端和服务端建立连接时的初始化握手。客户端发送initialize方法，服务端results回复确定版本和返回支持的功能。初始化过程是MCP生命周期管理的关键部分，其服务有几个目的：

协议版本协商：protocolVersion字段确保客户端和服务端使用兼容的协议版本，可以防止不同版本尝试交互是可能发生通信错误，如果未能协商出相互兼容的版本，则应该终止连接。
能力发现：capabilities对象允许每一方声明他们支持的功能，包括他们可以处理的基元（工具、资源、提示）以及是否支持通知等特性。通过避免不支持的操作来实现高效通信。
身份交换：clientInfo和serverInfo对象提供用于调试和兼容性目的的识别和版本信息。

上面的示例中能力协商展示了如何声明MCP原语：

客户端的功能

“elicitation”: {} – 客户端声明可以处理用户交互请求（可以接收 elicitation/create 方法调用）

服务端的功能：

“tools”: {“listChanged”: true} – 服务器支持工具原语，并且在其工具列表发生变化时可以发送 tools/list_changed 通知
“resources”: {} – 服务器也支持资源原语（可以处理 resources/list 和 resources/read 方法）

最后初始化成功后，客户端再发送同志表示已准备就绪

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

在初始化过程中，AI application的MCP client管理器连接到server后，并将它们的能力存储起来以供后续使用。应用程序使用这些信息来确定那些server可以提供特定类型的功能（tools、resource、prompts），以及它们是否支持实时更新。下面是AI application初始化伪代码。

# Pseudo Code
async with stdio_client(server_config) as (read, write):
    async with ClientSession(read, write) as session:
        init_response = await session.initialize()
        if init_response.capabilities.tools:
            app.register_mcp_server(session, supports_tools=True)
        app.set_server_ready(session)

工具发现

连接建立成功后，client可以通过发送tools/list请求发现可用的工具。这个请求是MCP工具发现机制的基础，他允许client在尝试使用工具之前了解server有那些可用的工具。

工具列表请求：

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list"
}

工具列表请求很简单，tools/list的方法，不包含任何参数。

工具列表回复

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "calculator_arithmetic",
        "title": "Calculator",
        "description": "Perform mathematical calculations including basic arithmetic, trigonometric functions, and algebraic operations",
        "inputSchema": {
          "type": "object",
          "properties": {
            "expression": {
              "type": "string",
              "description": "Mathematical expression to evaluate (e.g., '2 + 3 * 4', 'sin(30)', 'sqrt(16)')"
            }
          },
          "required": ["expression"]
        }
      },
      {
        "name": "weather_current",
        "title": "Weather Information",
        "description": "Get current weather information for any location worldwide",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name, address, or coordinates (latitude,longitude)"
            },
            "units": {
              "type": "string",
              "enum": ["metric", "imperial", "kelvin"],
              "description": "Temperature units to use in response",
              "default": "metric"
            }
          },
          "required": ["location"]
        }
      }
    ]
  }
}

响应包含一个tools数组，该数组提供了关于每个可用的工具全面元数据。这种基于数组的结构允许服务端同时暴露多个工具，同时保持不同功能之间的清晰界限。

响应中给每个工具对象包含几个关键字段：

name：服务器命名空间内工具的唯一标识符。这作为工具执行的主键，应遵循清晰的命名模式（例如， calculator_arithmetic 而不是仅仅 calculate ）。
title : 客户端可以向用户展示的工具的可读显示名称。
description : 该工具的作用是什么以及何时使用它的详细说明。
inputSchema : 一个 JSON Schema，定义了预期的输入参数，支持类型验证并提供关于必需和可选参数的清晰文档。

inputSchema是描述tool需要的输入参数的规范，告诉LLM参数叫什么、类型是什么，有那些枚举、那些字段是必填，是否有默认值。结构如下：

inputSchema
   └── type: object   ← 输入是一个对象
   └── properties      ← 参数的列表（有那些参数）
         ├── expression   ← 参数1，不要被expression迷惑只是一个参数的命名。
         └── location     ← 参数2
         └── units        ← 参数3
   └── required       ← 哪些字段必须提供

AI application从所有连接的MCP server获取可用的tools，并将它们组合成一个语言模型可以访问的统一工具注册表。这使得LLM能够了解他可以执行那些操作，并在对话期间自动生成相应的工具调用。下面是python tools发现的伪代码。

# Pseudo-code using MCP Python SDK patterns
available_tools = []
for session in app.mcp_server_sessions():
    tools_response = await session.list_tools()
    available_tools.extend(tools_response.tools)
conversation.register_available_tools(available_tools)

工具执行

客户端现在可以使用tools/call的方法执行一个tool，这展示了MCP 原语在实际中的使用方式：在发现可用工具后，客户端可以用适当的参数调用它们。

理解工具执行的请求

tools/call请求遵循结构化格式，确保客户端和服务端之间的类型安全和清晰通信，请注意，我们使用的是发现响应中的正确工具名称，而不是简化名称。

工具调用请求：

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "San Francisco",
      "units": "imperial"
    }
  }
}

请求结构包含几个重要的组件：

name：必须与发现响应中的工具名称（ weather_current ）完全匹配。这确保服务器能够正确识别要执行哪个工具。
arguments : 包含工具的 inputSchema 定义的输入参数。
JSON-RPC 结构：使用标准的 JSON-RPC 2.0 格式，并使用独特的 id 进行请求-响应关联。

工具调用响应：

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Current weather in San Francisco: 68°F, partly cloudy with light winds from the west at 8 mph. Humidity: 65%"
      }
    ]
  }
}

content 数组：工具响应返回一个内容对象数组，允许进行丰富、多格式的响应（文本、图像、资源等）。
Content Types：每个内容对象都有一个 type 字段。在这个例子中， “type”: “text” 表示纯文本内容，但 MCP 支持多种内容类型以适应不同的使用场景。
Structured Output：结构化输出，该响应提供可操作的资讯，供 AI 应用作为语言模型交互的上下文使用。

当语言模型在对话中决定使用工具时，AI application会拦截工具调用，将其路由到适当的MCP服务器执行该调用，并将结果作为对话流程的一部分返回给LLM。这使LLM能够访问实时数据并在外部世界执行操作。下面是工具调用的是示例操作：

# Pseudo-code for AI application tool execution
async def handle_tool_call(conversation, tool_name, arguments):
    session = app.find_mcp_session_for_tool(tool_name)
    result = await session.call_tool(tool_name, arguments)
    conversation.add_tool_result(result.content)

实时更新

MCP支持实时通知，使server能够在未被明确请求的情况下通知客户端有关变更，这展示了通知系统，这是一个关键特性，它使MCP连接保持同步和响应。

当服务器的可用tool发生变化时，例如新功能可用、现有工具被修改或工具暂时不可用，服务端可以主动通知连接的客户端。

{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed"
}

notifications有关键的特性

No Response Required: 请注意通知中没有 id 字段。这遵循 JSON-RPC 2.0 通知的语义，即不期望或发送响应。
Capability-Based:此通知仅由在初始化期间（如步骤 1 所示）在其工具能力中声明了 “listChanged”: true 的服务器发送。
Event-Driven:服务器根据内部状态变化决定何时发送通知，使 MCP 连接动态且响应迅速。

客户端收到notification后，客户端通常会通过请求更新的工具列表做出反应，这会形成一个刷新周期，使客户端对可用工具的理解保持最新：

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/list"
}

当ai application收到关于tools变更的通知时，它会理解刷新其工具注册表并更新LLM的可用功能。这确保了正在进行的对话始终能够访问最新的一套工具，并LLM可以随着新功能的可用而动态适应。

# Pseudo-code for AI application notification handling
async def handle_tools_changed_notification(session):
    tools_response = await session.list_tools()
    app.update_available_tools(session, tools_response.tools)
    if app.conversation.is_active():
        app.conversation.notify_llm_of_new_capabilities()

MCP Server

MCP Server是通过标准协议接口向AI applicant提供功能的应用程序，常见例子包括文档访问的文件系统服务器、用于数据查询的数据库服务器、用于代码管理的Github服务器、用于团队沟通的slack服务器以及用于日程安排的日历服务器。

服务器通过3个构建模块提供功能：

tools：LLM可以主动调用的功能，并根据用户请求决定何时使用它们。工具可以写入数据库、调用外部API、修改文件或触发其他逻辑。比如搜索航班、发送消息、创建日历事件。由模型来控制。
resources：提供只读访问权限以获取上下文信息的被动数据源，例如文件内容、数据库模式或API文档。比如检索文档、访问知识库、读取日历等。由application来控制。
prompts：预构建的指令模版，告诉模型如何使用特定的工具和资源。比如计划假期、总结我的会议、起草一封电子邮件等。由用户来控制。

下面假设一个场景来展示每个工具的作用，并介绍如何协同工作。

tools

工具使AI模型能够执行操作，每个tool定义了具有类型输入和输出的特定操作，模型根据上下文请求工具执行。

（1）tools如何工作的

具体的工作原理是LLMs可以调用的模式定义接口，MCP使用JSON Schema进行验证。每个工具执行一个具有明确定义的输入和输出的单一操作。tools在执行前可能需要用户同意，这有助于确保用户对模型采取的操作保持控制。

协议的操作：

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"]
  }
}

（2）示例：旅行预定

tools使ai applicantion能够udaibiao用户执行操作，在旅行规划场景中，AI应用程序可能会使用多个工具来帮助预定假期。

航班的搜索：查询多个航班公司并返回结构化的航班选型。

searchFlights(origin: "NYC", destination: "Barcelona", date: "2024-06-15")

日历的阻止：在用户的日历中标记旅行日期。

createCalendarEvent(title: "Barcelona Trip", startDate: "2024-06-15", endDate: "2024-06-22")

邮件的通知：向同事发送自动的离境邮件。

sendEmail(to: "team@work.com", subject: "Out of Office", body: "...")

（3）用户交互模型

工具由模型控制，这意味着AI模型可以自动的发型和调用它们。然而，MCP通过多种机制强调人工监督。

为了信任和安全，应用程序可以通过各种机制实现用户控制，例如：

在 UI 中显示可用工具，使用户能够定义工具是否应在特定交互中可用
单个工具执行的审批对话框
预先批准某些安全操作的权限设置
显示所有工具执行及其结果的活动日志

resources

资源为AI应用程序提供结构化访问信息，这些信息可以被应用程序检索并提供给模型作为上下文。

（1）resources如何工作的

资源从文件、API、数据库或其他AI需要理解上下文的任何来源中暴露数据。应用程序可以直接访问这些信息并决定如何使用它，无论是选择相关的部分、使用嵌入进行搜索，还是将所有信息传递给模型。

每个资源都有一个唯一的URI（例如， file:///path/to/document.md），并声明其MIME类型以进行适当的内容处理。

resources支持两种发现模式：

Direct Resources：指向特定数据的固定 URI。示例： calendar://events/2024 – 返回 2024 年的日历可用性。
Resource Templates：带参数的动态 URI，用于灵活查询。

资源模板包含标题、描述和预期 MIME 类型等元数据，使其可发现且自描述。下面是协议操作：

resources/list：目的是列出可用的直接资源，返回的是资源描述符数组。
resources/templates/list：目的是发现资源的模版，返回的是资源模版定义数组。
resources/read：目的是获取资源内容，返回的是带元数据的资源数据。
resources/subscribe：目的是监控资源变化，返回的是订阅确认。

（2）示例：获取旅行规划上下文

继续以旅行规划为例，resources为AI application提供访问相关信息的方式：

Calendar data：calendar://events/2024，日历数据，检查用户可用性。
Travel documents ：file:///Documents/Travel/passport.pdf，访问重要文件。
Previous itineraries：trips://history/barcelona-2023，参考过去的旅行和偏好。

AI应用检索这些资源，并决定如何处理它们，无论是使用嵌入或关键词搜索选择数据子集，还是将原始数据直接传递给模型。在这种情况下，它向模型提供日历数据、天气信息和旅行偏好，使模型能够检查可用性、查询天气模式并参考过去的旅行偏好。

下面是resource模版示例：

{
  "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作为origin机场，并开始输入Bar作为destination机场时，系统可以建议BCN或BGI。

（3）用户交互模型

resources有营养程序驱动，使其在获取、处理和呈现可用上下文方面具有灵活性，常见的交互模式包括：

用于在熟悉的类似文件夹的结构中浏览资源的树形或列表视图。
用于查找特定资源的搜索和筛选界面
基于启发式或 AI 选择的自动上下文包含或智能建议
用于包含单个或多个资源的手动或批量选择界面

Prompts

提示提供可重用的模版，它们允许MCP服务器为特定领域提供参数化提示，或展示如何最佳使用MCP服务器。

（1）Prompts如何工作的

提示是定义预期输入和交互模式的结构化模版。它们由用户控制，需要显示调用而非自动触发。提示可以感知上下文，引用可用的资源和工具来创建全面的流程。下面是协议的操作：

prompts/list：目的是发现可用提示，返回的是提示描述符数组。
prompts/get：目的是检索提示详情，返回的是带参数的完整提示定义。

（2）示例

提示为场景任务提供结构化的模版。

{
  "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" } }
  ]
}

MCP Client

MCP client由主机应用程序实例化，用于与特定的MCP server进行通信。主机应用程序，如claude.ai或集成开发环境IDE，管理整体用户体验并协调多个客户端。每个客户端负责与一个server进行直接通信。host是用户交互的应用程序，而client是使能server连接的协议级组件。

除了利用server提供上下文外，client还可以向server提供多种功能。这些client功能使server开发能够构建更丰富的交互。

sampling：采样允许server通过client请求LLM补全，从实现代理式工作流程。这种方法将用户权限和安全措施完全至于客户端的控制之下。比如一个用于预定旅行的服务器可以向LLM发送航班列表，并请求LLM为用户挑选最佳航班。
Roots：Roots允许客户端指定服务器应关注的目录，通过协调机制传达预期的范围。比如一个用于预定旅行的服务器可能会被授予特定目录的权限，从中可以读取用户的日历。
Elicitaion：交互式信息提取使服务器能够在交互过程中请求的特定信息，为服务器按需收集信息提供了一种结构化的方式。比如预定旅行的服务器可能会询问用户对飞机座位、房间类型或联系方式的偏好。

Elicitaion

交互式信息提取使server能够在交互过程中请求特定信息，创建更动态和响应迅速的工作流程。

（1）概述

Elicitaion提供了一种结构化的方式，让server按需收集必要信息。server不再需要一开始就获取所有信息或在数据缺失时失败，而是可以暂停操作，向用户请求特定的输入。者创造了更灵活的交互方式，server能够根据用户需求进行调整，而不是遵循僵化的模式。下面提取的流程：

该流程支持动态信息收集，server在需要时可以请求特定的数据，用户通过合适的界面提供信息，server则继续使用新获取的上下文进行后续处理。

（2）示例

提取组件的示例如下：

{
  method: "elicitation/requestInput",
  params: {
    message: "Please confirm your Barcelona vacation booking details:",
    schema: {
      type: "object",
      properties: {
        confirmBooking: {
          type: "boolean",
          description: "Confirm the booking (Flights + Hotel = $3,000)"
        },
        seatPreference: {
          type: "string",
          enum: ["window", "aisle", "no preference"],
          description: "Preferred seat type for flights"
        },
        roomType: {
          type: "string",
          enum: ["sea view", "city view", "garden view"],
          description: "Preferred room type at hotel"
        },
        travelInsurance: {
          type: "boolean",
          default: false,
          description: "Add travel insurance ($150)"
        }
      },
      required: ["confirmBooking"]
    }
  }
}

Roots

roots定义服务器操作的文件系统边界，允许客户端指定服务器应关注的目录。

roots是client向server传到文件系统访问边界的机制，它们由指示服务器可以操作的目录文件URI组成，帮助server理解可用文件和文件夹的范围。虽然roots传到了预期的边界，但他们并不强制执行安全显示。实际的安全必须在操作系统级别通过文件权限或沙盒机制来强制执行。

下面是roots结构

{
  "uri": "file:///Users/agent/travel-planning",
  "name": "Travel Planning Workspace"
}

roots是专有的文件系统路径，始终使用file:// 的URL方案，它们帮助server理解项目边界、工作空间组织和可访问的目录。根列表可以根据用户在不同项目或文件夹中工作动态更新，当边界发生变化时，服务器通过roots/list_changed接收通知。

sampling

采样允许server通过client请求语言模型补全，在保持安全性和用户控制的同时，实现代理行为。

采样使server能够在不直接继承或支付AI模型费用的情况下执行依赖AI的任务。相反，服务器可以请求已经具有AI模型访问权限的客户代表它们处理这些任务。这种方法将用户权限和安全措施完全置于客户控制之下。由于采样请求发生在其他操作的上下文中，并且作为单独的模型调用进行处理，它们在不同上下文之间保持清晰的界限，从而能够更有效地使用上下文窗口。

该流程通过多个人工审核环境确保安全性。用户可以在响应返回server之前，审查并修改初始请求和生成的响应。

{
  messages: [
    {
      role: "user",
      content: "Analyze these flight options and recommend the best choice:\n" +
               "[47 flights with prices, times, airlines, and layovers]\n" +
               "User preferences: morning departure, max 1 layover"
    }
  ],
  modelPreferences: {
    hints: [{
      name: "claude-sonnet-4-20250514"  // Suggested model
    }],
    costPriority: 0.3,      // Less concerned about API cost
    speedPriority: 0.2,     // Can wait for thorough analysis
    intelligencePriority: 0.9  // Need complex trade-off evaluation
  },
  systemPrompt: "You are a travel expert helping users find the best flights based on their preferences",
  maxTokens: 1500
}

本文主要来自官方文档的翻译：https://modelcontextprotocol.io/docs/getting-started/intro