Skip to main content
MCP 服务器是通过标准化协议接口向 AI 应用程序暴露特定能力的程序。 常见示例包括用于文档访问的文件系统服务器、用于数据查询的数据库服务器、用于代码管理的 GitHub 服务器、用于团队通信的 Slack 服务器以及用于调度的日历服务器。

核心服务器功能

服务器通过三个构建块提供功能: 我们将使用一个假设的场景来演示每个功能的作用,并展示它们如何协同工作。

工具

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

工具如何工作

工具是 LLM 可以调用的模式定义接口。MCP 使用 JSON Schema 进行验证。每个工具执行具有明确定义输入和输出的单个操作。工具在执行前可能需要用户同意,有助于确保用户保持对模型所采取行动的控制。 协议操作: 示例工具定义:

示例:旅行预订

工具使 AI 应用程序能够代表用户执行操作。在旅行计划场景中,AI 应用程序可能会使用几个工具来帮助预订假期: 航班搜索
查询多家航空公司并返回结构化航班选项。 日历锁定
在用户日历中标记旅行日期。 电子邮件通知
向同事发送自动化的外出办公消息。

用户交互模型

工具由模型控制,意味着 AI 模型可以自动发现并调用它们。然而,MCP 通过多种机制强调人工监督。 为了信任和安全,应用程序可以通过各种机制实现用户控制,例如:
  • 在 UI 中显示可用工具,使用户能够定义是否应在特定交互中提供工具
  • 用于单个工具执行的批准对话框
  • 用于预先批准某些安全操作的权限设置
  • 显示所有工具执行及其结果的活动日志

资源

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

资源如何工作

资源公开来自文件、API、数据库或 AI 需要理解上下文的任何其他来源的数据。应用程序可以直接访问这些信息并决定如何使用它——无论是选择相关部分、使用嵌入进行搜索,还是将其全部传递给模型。 每个资源都有一个唯一的 URI(例如 file:///path/to/document.md)并声明其 MIME 类型以进行适当的内容处理。 资源支持两种发现模式:
  • 直接资源 - 指向特定数据的固定 URI。示例:calendar://events/2024 - 返回 2024 年的日历可用性
  • 资源模板 - 带有参数的动态 URI,用于灵活查询。示例:
    • travel://activities/{city}/{category} - 按城市和类别返回活动
    • travel://activities/barcelona/museums - 返回巴塞罗那的所有博物馆
资源模板包括元数据,如标题、描述和预期的 MIME 类型,使它们可被发现且自我文档化。 协议操作:

示例:获取旅行计划上下文

继续旅行计划示例,资源为 AI 应用程序提供对相关信息的访问:
  • 日历数据 (calendar://events/2024) - 检查用户可用性
  • 旅行文档 (file:///Documents/Travel/passport.pdf) - 访问重要文档
  • 以前的行程 (trips://history/barcelona-2023) - 参考过去的旅行和偏好
AI 应用程序检索这些资源并决定如何处理它们,无论是使用嵌入或关键词搜索选择数据子集,还是将原始数据直接传递给模型。 在这种情况下,它向模型提供日历数据、天气信息和旅行偏好,使其能够检查可用性、查找天气模式并参考过去的旅行偏好。 资源模板示例:
这些模板支持灵活查询。对于天气数据,用户可以访问任何城市/日期组合的预报。对于航班,他们可以搜索任何两个机场之间的路线。当用户输入 “NYC” 作为 origin 机场并开始输入 “Bar” 作为 destination 机场时,系统可以建议 “Barcelona (BCN)” 或 “Barbados (BGI)“。

参数补全

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

用户交互模型

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

提示

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

提示如何工作

提示是定义预期输入和交互模式的结构化模板。它们由用户控制,需要显式调用而不是自动触发。提示可以感知上下文,引用可用资源和工具以创建综合工作流。与资源类似,提示支持参数补全以帮助用户发现有效的参数值。 协议操作:

示例:简化工作流

提示为常见任务提供结构化模板。在旅行计划上下文中: “计划假期”提示:
与非结构化自然语言输入相比,提示系统支持:
  1. 选择“计划假期”模板
  2. 结构化输入:Barcelona, 7 days, $3000, [“beaches”, “architecture”, “food”]
  3. 基于模板的一致工作流执行

用户交互模型

提示由用户控制,需要显式调用。协议赋予实现者自由,在其应用程序中设计感觉自然的界面。关键原则包括:
  • 轻松发现可用提示
  • 清楚描述每个提示的作用
  • 带有验证的自然参数输入
  • 透明显示提示的底层模板
应用程序通常通过多种 UI 模式暴露提示,例如:
  • 斜杠命令(输入 ”/” 以查看可用提示,如 /plan-vacation)
  • 用于可搜索访问的命令面板
  • 用于常用提示的专用 UI 按钮
  • 建议相关提示的上下文菜单

将服务器整合在一起

当多个服务器通过统一接口协同工作,结合其专业能力时,MCP 的真正威力才会显现。

示例:多服务器旅行规划

设想一个个性化的 AI 旅行规划应用程序,连接了三个服务器:
  • 旅行服务器 - 处理航班、酒店和行程
  • 天气服务器 - 提供气候数据和预报
  • 日历/邮件服务器 - 管理日程和通信

完整流程

  1. 用户调用带有参数的提示词:
  2. 用户选择要包含的资源:
    • calendar://my-calendar/June-2024(来自日历服务器)
    • travel://preferences/europe(来自旅行服务器)
    • travel://past-trips/Spain-2023(来自旅行服务器)
  3. AI 使用工具处理请求: AI 首先读取所有选定的资源以收集上下文——从日历中识别可用日期,从旅行偏好中学习首选航空公司和酒店类型,并从过去的行程中发现以前喜欢过的地点。 使用这些上下文后,AI 接着执行 AI 应用程序提供的提示词。在我们的示例中,AI 应用程序将已连接的 MCP 天气服务器中的天气工具暴露给模型。由于天气会影响旅行计划,AI 在解释提示词时选择调用 checkWeather() 结果,AI 执行了一系列工具:
    • searchFlights() - 查询从纽约到巴塞罗那的航班
    • checkWeather() - 获取旅行日期的气候预报
    然后,AI 使用这些信息创建预订及后续步骤,并在必要时请求用户批准:
    • bookHotel() - 查找指定预算内的酒店
    • createCalendarEvent() - 将行程添加到用户的日历
    • sendEmail() - 发送包含行程详情的确认邮件
结果: 通过多个 MCP 服务器,用户研究并预订了符合其日程安排的巴塞罗那之旅。“计划假期”提示词引导 AI 跨不同服务器结合资源(日历可用性和旅行历史)与工具(搜索航班、预订酒店、更新日历)——收集上下文并执行预订。使用 MCP,原本可能需要数小时的任务在几分钟内就完成了。