02 Tools Resources Prompts

MCP Server对外提供能力时，最重要的三个构件是Tools、Resources和Prompts。它们分别对应“执行动作”“读取上下文”和“复用提示词模板”。

这三类能力的职责不同，使用方式也不同。设计MCP Server时，先区分能力类型，再决定暴露方式，可以避免把所有功能都做成工具。

一、三类能力对比

能力	主要作用	是否执行动作	典型控制方	示例
Tools	让模型调用外部操作	是	模型选择，应用确认	查询数据库、发送消息、创建Issue
Resources	向应用提供上下文数据	否，通常只读	Host或用户选择	文件内容、数据库schema、文档页面
Prompts	提供可复用任务模板	否	用户或应用显式选择	代码审查模板、总结模板、排障模板

一个经验规则是：

• 会产生动作或副作用的能力，优先设计成Tool。
• 只是提供数据给模型理解的能力，优先设计成Resource。
• 需要沉淀成可复用任务流程的内容，适合设计成Prompt。

二、Tools

Tools是MCP中最常用的能力。它表示Server暴露给模型调用的可执行函数。

一个Tool通常包含：

字段	说明
name	工具唯一标识
description	工具用途说明，帮助模型判断何时调用
inputSchema	输入参数的JSON Schema
outputSchema	可选，结构化输出定义
annotations	可选，用于描述工具行为

工具发现通过tools/list完成，工具调用通过tools/call完成。

{
  "name": "search_docs",
  "description": "搜索企业内部知识库",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "搜索关键词"
      }
    },
    "required": ["query"]
  }
}

2.1 工具适合做什么

Tools适合封装有明确输入和输出的操作：

• 查询数据库
• 搜索文档
• 调用第三方API
• 创建工单
• 发送通知
• 修改文件
• 触发构建或部署流程

如果工具会写入数据、删除数据、发送消息或触发生产动作，应在Host层或Server层加入权限校验、确认机制和审计日志。

2.2 工具设计原则

工具定义会直接影响模型是否能正确使用。设计时应遵循以下原则：

1. 单一职责：一个工具只做一类明确动作。
2. 名称稳定：工具名应使用稳定、可读、无歧义的命名。
3. 描述具体：说明工具做什么、何时使用、输入约束是什么。
4. 参数清晰：用schema约束类型、必填字段和枚举值。
5. 错误可读：返回可理解的错误信息，便于模型修正参数。
6. 副作用受控：写入、删除、发送类工具需要更严格的安全控制。

不推荐把过大的业务流程压进单个工具。过大的工具不利于模型选择，也不利于权限控制和调试。

三、Resources

Resources用于向Client暴露可读取的数据。它们更像“上下文入口”，而不是“动作按钮”。

常见Resource包括：

• 项目文件
• API文档
• 数据库表结构
• 企业知识库页面
• 日历记录
• 配置说明

每个Resource都有唯一URI，例如：

file:///project/README.md
docs://python/logging
db://schema/orders

Client可以通过resources/list发现资源，通过resources/read读取资源内容。

3.1 固定资源

固定资源适合暴露明确存在的内容：

{
  "uri": "docs://handbook/reimbursement",
  "name": "reimbursement-policy",
  "title": "报销制度",
  "description": "企业内部报销制度说明",
  "mimeType": "text/markdown"
}

这种资源可以被Host展示在资源列表中，由用户或应用选择是否加入上下文。

3.2 资源模板

资源模板用于暴露带参数的资源。典型场景是按路径、ID、关键词读取内容。

{
  "uriTemplate": "docs://article/{slug}",
  "name": "article",
  "title": "文章内容",
  "description": "按slug读取文章正文",
  "mimeType": "text/markdown"
}

资源模板适合以下场景：

• 按文件路径读取内容
• 按文章slug读取文档
• 按表名读取数据库schema
• 按用户ID读取只读资料

Resources通常由Host或用户控制，而不是由模型直接任意调用。这样可以让上下文选择更可控。

四、Prompts

Prompts用于提供可复用的提示词模板。它们不是工具，也不是数据源，而是一种标准化任务入口。

常见Prompt包括：

• 总结会议记录
• 生成代码审查意见
• 根据日志分析故障
• 根据需求生成测试用例
• 使用某组工具完成固定流程

Prompt可以带参数：

{
  "name": "review-code",
  "title": "代码审查",
  "description": "根据指定语言和关注点生成代码审查提示词",
  "arguments": [
    {
      "name": "language",
      "type": "string",
      "required": true
    },
    {
      "name": "focus",
      "type": "string",
      "required": false
    }
  ]
}

Prompts通常由用户或应用显式触发，而不是由模型自动调用。它适合沉淀团队内部的标准任务流程。

五、如何选择暴露方式

设计MCP Server时，可以按以下问题判断使用哪种能力：

问题	推荐能力
是否需要执行外部动作	Tools
是否只是读取上下文	Resources
是否是可复用任务模板	Prompts
是否有副作用	Tools，并加入确认和审计
是否需要由用户主动选择	Resources或Prompts
是否需要被模型根据上下文自动选择	Tools

示例：

需求	推荐设计
查询订单状态	Tool：query_order_status
暴露订单表结构	Resource：db://schema/orders
生成订单异常排查提示词	Prompt：troubleshoot-order
修改订单备注	Tool：update_order_note，需要权限控制
读取项目README	Resource：file:///project/README.md

六、组合使用示例

一个内部文档MCP Server可以这样设计：

能力	示例
Tool	search_docs(query)：搜索文档
Resource	docs://article/{slug}：读取具体文章
Prompt	summarize-doc(slug)：生成总结任务模板

调用流程可以是：

1. 用户提出问题。
2. 模型调用search_docs搜索相关文档。
3. Host读取docs://article/{slug}作为上下文。
4. 用户选择summarize-doc模板生成标准总结。

这种拆分让工具调用、上下文读取和任务模板各自保持清晰边界。

七、总结

Tools、Resources和Prompts是MCP Server设计的核心。

能力	设计重点
Tools	清晰参数、单一职责、安全确认、审计记录
Resources	稳定URI、只读上下文、合理MIME类型
Prompts	明确用途、参数化模板、用户显式选择

良好的MCP Server不是把所有能力都做成工具，而是根据能力性质选择合适的协议构件。