核心服务器功能
服务器通过三个构建块提供功能:
我们将使用一个假设的场景来演示每个功能的作用,并展示它们如何协同工作。
工具
工具使 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- 返回巴塞罗那的所有博物馆
示例:获取旅行计划上下文
继续旅行计划示例,资源为 AI 应用程序提供对相关信息的访问:- 日历数据 (
calendar://events/2024) - 检查用户可用性 - 旅行文档 (
file:///Documents/Travel/passport.pdf) - 访问重要文档 - 以前的行程 (
trips://history/barcelona-2023) - 参考过去的旅行和偏好
origin 机场并开始输入 “Bar” 作为 destination 机场时,系统可以建议 “Barcelona (BCN)” 或 “Barbados (BGI)“。
参数补全
动态资源支持参数补全。例如:- 输入 “Par” 作为
weather://forecast/{city}的输入可能会建议 “Paris” 或 “Park City” - 为
flights://search/{airport}输入 “JFK” 可能会建议 “JFK - John F. Kennedy International”
用户交互模型
资源由应用程序驱动,使它们在检索、处理和呈现可用上下文方面具有灵活性。常见交互模式包括:- 用于以熟悉的文件夹类似结构浏览资源的树或列表视图
- 用于查找特定资源的搜索和过滤界面
- 基于启发式或 AI 选择的自动上下文包含或智能建议
- 用于包含单个或多个资源的手动或批量选择界面
提示
提示提供可重用的模板。它们允许 MCP 服务器作者为域提供参数化提示,或展示如何最好地使用 MCP 服务器。提示如何工作
提示是定义预期输入和交互模式的结构化模板。它们由用户控制,需要显式调用而不是自动触发。提示可以感知上下文,引用可用资源和工具以创建综合工作流。与资源类似,提示支持参数补全以帮助用户发现有效的参数值。 协议操作:示例:简化工作流
提示为常见任务提供结构化模板。在旅行计划上下文中: “计划假期”提示:- 选择“计划假期”模板
- 结构化输入:Barcelona, 7 days, $3000, [“beaches”, “architecture”, “food”]
- 基于模板的一致工作流执行
用户交互模型
提示由用户控制,需要显式调用。协议赋予实现者自由,在其应用程序中设计感觉自然的界面。关键原则包括:- 轻松发现可用提示
- 清楚描述每个提示的作用
- 带有验证的自然参数输入
- 透明显示提示的底层模板
- 斜杠命令(输入 ”/” 以查看可用提示,如 /plan-vacation)
- 用于可搜索访问的命令面板
- 用于常用提示的专用 UI 按钮
- 建议相关提示的上下文菜单
将服务器整合在一起
当多个服务器通过统一接口协同工作,结合其专业能力时,MCP 的真正威力才会显现。示例:多服务器旅行规划
设想一个个性化的 AI 旅行规划应用程序,连接了三个服务器:- 旅行服务器 - 处理航班、酒店和行程
- 天气服务器 - 提供气候数据和预报
- 日历/邮件服务器 - 管理日程和通信
完整流程
-
用户调用带有参数的提示词:
-
用户选择要包含的资源:
calendar://my-calendar/June-2024(来自日历服务器)travel://preferences/europe(来自旅行服务器)travel://past-trips/Spain-2023(来自旅行服务器)
-
AI 使用工具处理请求:
AI 首先读取所有选定的资源以收集上下文——从日历中识别可用日期,从旅行偏好中学习首选航空公司和酒店类型,并从过去的行程中发现以前喜欢过的地点。
使用这些上下文后,AI 接着执行 AI 应用程序提供的提示词。在我们的示例中,AI 应用程序将已连接的 MCP 天气服务器中的天气工具暴露给模型。由于天气会影响旅行计划,AI 在解释提示词时选择调用
checkWeather()。 结果,AI 执行了一系列工具:searchFlights()- 查询从纽约到巴塞罗那的航班checkWeather()- 获取旅行日期的气候预报
bookHotel()- 查找指定预算内的酒店createCalendarEvent()- 将行程添加到用户的日历sendEmail()- 发送包含行程详情的确认邮件