MCP 入门（三）：工具、资源、提示词 —— 服务器的三驾马车

MCP 服务器，简单说就是通过标准化协议接口，向 AI 应用提供特定能力的程序。

听起来有点抽象？举几个例子你就明白了：文件系统服务器让 AI 能访问文档，数据库服务器让 AI 能查数据，GitHub 服务器让 AI 能管代码，Slack 服务器让 AI 能发消息，日历服务器让 AI 能安排日程。

一句话概括：MCP 服务器让 AI 从"只会聊天"变成了"能干实事"。

MCP 服务器的三大核心能力

核心能力分三块，我先用一张表让你建立整体印象：

功能	一句话解释	示例	谁控制
工具（Tools）	LLM 可以主动调用的功能，根据用户请求决定何时使用。可以写数据库、调 API、改文件或触发其他操作	查航班、发消息、创建日程	模型
资源（Resources）	提供上下文信息只读访问的被动数据源，比如文件内容、数据库模式、API 文档	检索文档、访问知识库、读日历	应用
提示词（Prompts）	预构建的指令模板，引导模型使用特定工具和资源来完成工作	计划假期、总结会议、起草邮件	用户

注意最后一列"谁控制" – 这个设计很关键。工具由模型自主决定调用，资源由应用程序管理，提示词由用户显式触发。三者各有主人，协作但不越界。

下面我用一个贯穿全文的旅行预订场景，逐个拆解这三大能力。

工具（Tools）：让 AI 能"动手"

工具让 LLM 不再只是输出文字，而是能真正执行操作。每个工具都针对特定功能设计，具有严格定义的输入输出。LLM 会根据对话上下文，自行判断该调用哪个工具。

工具是怎么工作的？

技术层面，工具是由 JSON Schema 定义的接口，LLM 可以直接调用。MCP 用 JSON Schema 做参数校验，确保调用合规。

重要的一点：工具执行前需要用户同意。 这保证了人类对 AI 操作始终拥有控制权。

协议操作

方法	目的	返回
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 帮用户完成一连串实际操作：

1. 搜航班

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

查询多条航线，返回结构化的可选航班列表。

2. 标日历

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

把旅程自动写入用户日历。

3. 发邮件

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

自动向同事发送"外出不在办公室"的通知邮件。

看到没？从搜航班到标日历再到发邮件，AI 一气呵成。这就是工具的价值 – 让 AI 从"建议者"变成"执行者"。

安全机制：人始终在回路中

工具虽然由模型控制，AI 会自动发现并调用它们，但 MCP 非常强调人类监督。应用可以通过多种机制实施用户控制：

• 在界面中展示可用工具，让用户决定在当前对话中是否启用某个工具
• 执行工具前弹出审批对话框
• 提前设置权限，预批准特定的安全操作
• 提供活动日志，展示所有工具的执行过程和结果

资源（Resources）：给 AI 喂上下文

如果说工具是 AI 的"手脚"，那资源就是 AI 的"眼睛"。资源提供对信息的结构化访问，AI 应用可以检索这些信息，作为上下文喂给模型。

资源是怎么工作的？

资源能从文件、API、数据库或任何数据源中提取信息。应用可以直接访问这些数据，然后自行决定怎么用 – 可以挑选相关片段，可以用向量搜索，也可以把原始数据直接丢给模型。

每个资源都有一个唯一 URI（比如 file:///path/to/document.md），并声明 MIME 类型以便正确处理内容。

简单解释两个概念：

• URI：资源的身份标识和定位地址，客户端通过它向服务器请求具体内容
• MIME 类型：告诉接收方"这份数据是什么格式"，比如 JSON、PDF 还是纯文本

资源支持两种发现模式：

• 直接资源：指向特定数据的固定 URI。比如 calendar://events/2024 返回 2024 年日历的可用性
• 资源模板：带参数的动态 URI，用于灵活查询。比如：
  • travel://activities/{city}/{category} 按城市和类别返回活动信息
  • travel://activities/barcelona/museums 返回巴塞罗那的所有博物馆

资源模板包含标题（title）、描述（description）和预期 MIME 类型，天然具备可发现性和自解释性。

什么意思？客户端不用硬编码去猜服务器有哪些数据，连上 MCP 服务器后，列出这些模板就能知道有哪些数据接口可用。而模板本身的结构就是文档 – LLM 读了元数据就知道怎么调用、怎么解析返回值。

协议操作

方法	目的	返回
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"
}

这些模板的灵活性在于：天气数据可以查任意城市、任意日期；航班数据可以搜任意两座城市间的航线。

参数补全：降低使用门槛

动态资源还支持参数补全，体验非常友好：

• 输入 “Par” 给 weather://forecast/{city}，系统会建议 “Paris” 或 “Park City”
• 输入 “JFK” 给 flights://search/{airport}，系统会建议 “JFK - John F. Kennedy International”

不需要记住精确格式，系统会帮你找到有效值。

交互模式：应用说了算

资源由应用驱动，在检索、处理和呈现上下文方面有很大的灵活度。常见的交互模式包括：

• 树形或列表视图浏览资源，类似文件管理器的体验
• 搜索和筛选界面，快速定位特定资源
• 基于启发式或 AI 选择的智能推荐和自动包含
• 手动或批量选择界面，一次选取多个资源

协议不强制规定具体的 UI 模式，这给了开发者充分的自由。 你可以做带预览功能的资源选择器，可以做基于对话上下文的智能推荐，可以做批量选择界面，也可以与现有的文件浏览器无缝集成。

提示词（Prompts）：给 AI 一套可复用的工作流模板

提示词提供可复用的模板。它让 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. 选择 “Plan a vacation” 模板
2. 结构化输入：Barcelona, 7 days, $3000, [“beaches”, “architecture”, “food”]
3. 基于模板执行一致的工作流

把不确定的自由输入变成确定的结构化流程 – 这就是提示词的核心价值。

交互设计：让用户轻松上手

提示词由用户控制，需要显式调用。界面设计的核心原则是：

• 轻松发现可用的提示词
• 清晰说明每个提示词的用途
• 自然的参数输入体验，带校验功能
• 透明展示底层模板内容

应用通常通过以下 UI 模式来呈现提示词：

• 斜杠命令：输入 “/” 查看可用提示词，比如 /plan-vacation
• 命令面板：支持搜索的提示词列表
• 专用按钮：为常用提示词设置快捷入口
• 上下文菜单：根据当前场景智能推荐相关提示词

多服务器协作：MCP 真正的杀手锏

单个 MCP 服务器已经很有用了，但当多个服务器通过统一接口协同工作、各展所长时，MCP 的真正威力才显现出来。

场景：多服务器旅行规划

一个个性化 AI 旅游规划应用，通常需要接入三类服务：

• 旅游服务：处理航班、酒店、行程安排
• 天气服务：提供气候数据和天气预报
• 日历/邮件服务：管理日程和通讯

完整流程

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 开始执行一系列工具调用：

• searchFlights()：查询纽约到巴塞罗那的航班
• checkWeather()：获取旅行日期的天气预报

AI 综合这些信息，制定预订方案和后续步骤，在必要时请求用户审批：

• bookHotel()：在预算范围内预订酒店
• createCalendarEvent()：将行程写入日历
• sendEmail()：发送确认邮件和行程详情

最终效果：通过多个 MCP 服务器的协作，用户根据自己的时间安排，完成了一次个性化旅行的调研和预订。“Plan a vacation” 提示词引导 AI 将不同服务器上的资源（日历可用性、旅行历史）与工具（搜航班、订酒店、更新日历）有机结合。

原本需要几个小时在不同网站间反复切换的事，用 MCP 几分钟就搞定了。 这就是标准化协议带来的效率飞跃。