核心服务器功能
服务器通过三个构建块提供功能:| 功能 | 解释 | 示例 | 控制者 |
|---|---|---|---|
| 工具 | 您的 LLM 可以主动调用的函数,并根据用户请求决定何时使用它们。工具可以写入数据库、调用外部 API、修改文件或触发其他逻辑。 | 搜索航班 发送消息 创建日历事件 | 模型 |
| 资源 | 被动数据源,为上下文提供信息的只读访问权限,例如文件内容、数据库模式或 API 文档。 | 检索文档 访问知识库 读取日历 | 应用程序 |
| 提示 | 预建的指令模板,告诉模型使用特定的工具和资源。 | 计划假期 总结我的会议 起草电子邮件 | 用户 |
工具
工具使 AI 模型能够执行操作。每个工具定义具有类型化输入和输出的特定操作。模型根据上下文请求工具执行。工具如何工作
工具是 LLM 可以调用的模式定义接口。MCP 使用 JSON Schema 进行验证。每个工具执行具有明确定义输入和输出的单个操作。工具在执行前可能需要用户同意,有助于确保用户保持对模型所采取行动的控制。 协议操作:| 方法 | 目的 | 返回 |
|---|---|---|
tools/list | 发现可用工具 | 带有模式的工具定义数组 |
tools/call | 执行特定工具 | 工具执行结果 |
示例:旅行预订
工具使 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- 返回巴塞罗那的所有博物馆
| 方法 | 目的 | 返回 |
|---|---|---|
resources/list | 列出可用直接资源 | 资源描述符数组 |
resources/templates/list | 发现资源模板 | 资源模板定义数组 |
resources/read | 检索资源内容 | 带有元数据的资源数据 |
resources/subscribe | 监控资源更改 | 订阅确认 |
示例:获取旅行计划上下文
继续旅行计划示例,资源为 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 服务器。提示如何工作
提示是定义预期输入和交互模式的结构化模板。它们由用户控制,需要显式调用而不是自动触发。提示可以感知上下文,引用可用资源和工具以创建综合工作流。与资源类似,提示支持参数补全以帮助用户发现有效的参数值。 协议操作:| 方法 | 目的 | 返回 |
|---|---|---|
prompts/list | 发现可用提示 | 提示描述符数组 |
prompts/get | 检索提示详情 | 带有参数的完整提示定义 |
示例:简化工作流
提示为常见任务提供结构化模板。在旅行计划上下文中: “计划假期”提示:- 选择“计划假期”模板
- 结构化输入: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 随后执行一系列工具:
searchFlights()- 查询航空公司关于纽约到巴塞罗那的航班checkWeather()- 检索旅行日期的气候预报
bookHotel()- 查找指定预算内的酒店createCalendarEvent()- 将行程添加到用户的日历sendEmail()- 发送包含行程详情的确认邮件