WebSearch与WebFetch

两个工具分工明确，形成"搜索 → 抓取"的完整流水线，下面从多个维度对比：

---

核心定位

维度	WebSearch	WebFetch
职责	发现页面（找链接）	读取页面（取内容）
输入	搜索关键词 query	明确的 URL + 问题 prompt
输出	相关页面的标题 + URL 列表	针对 prompt 问题的直接回答
类比	Google 搜索框	浏览器地址栏

---

内部实现差异（逆向分析结论）

WebSearch 调用的是 Anthropic 服务端的 web_search_20250305 工具，实际上用的是 Anthropic 自己的基础设施。它会派生一个次级 Claude Opus 对话来执行搜索，返回 10 条带加密内容的搜索结果，但 Claude Code 只提取其中的 title 和 url 字段。

WebFetch 则与预期不同——它不使用 Anthropic 的服务端 web fetch 工具，而是通过 Axios 在本地直接抓取页面 HTML，然后派生一个次级 Claude Haiku 对话来处理内容，最终 Haiku 的回答作为工具结果返回主对话。

WebSearch 调用链:
主对话 → [Anthropic 服务端 web_search] → Opus 次级对话 → 返回链接列表

WebFetch 调用链:
主对话 → [本地 Axios 抓页面] → Haiku 次级对话（回答问题）→ 返回答案摘要

---

关键设计决策

WebFetch 为什么用 Haiku 做预处理？

完整页面转换后通常有 10–100 KB，直接推入主模型（Sonnet/Opus）成本高且会挤占代码上下文。Haiku 预先过滤成"只回答这个问题"，让主对话保持紧凑。

WebFetch 的 URL 安全限制

出于安全考虑，WebFetch 只能抓取已出现在对话上下文中的 URL，包括用户直接提供的、或 WebSearch/WebFetch 结果中出现过的链接。Claude 不能自行构造 URL 去请求，防止数据外泄攻击。

---

典型协作流程

用户: "帮我查 Kubernetes Gateway API 最新变化"
        ↓
1. WebSearch("Kubernetes Gateway API 2025")
        ↓ 返回 10 条链接
2. WebFetch(url="...", prompt="总结主要变化")
        ↓ Haiku 处理原始 HTML → 返回摘要
3. 主对话综合回答用户

---

与 MCP 搜索插件的关系

内置的 WebSearch + WebFetch 组合可以满足约 80% 的日常搜索需求。如果需要更高的搜索质量或更精细的结果控制，可以叠加 Brave Search MCP（官方推荐，每月免费 2000 次）等插件，两者并不冲突。

---

一句话总结：WebSearch 是"找门"，WebFetch 是"进门读内容"。 两者通常串联使用，但也可以单独调用——比如你已知 URL，直接用 WebFetch 就够了。

ListMcpResourcesTool与ReadMcpResourceTool

Claude Code 作为 MCP 客户端时，用来与 MCP Server 的 Resources 原语交互的内置工具。

MCP Resources 回顾

在 MCP 协议中，Resources 和 Tools 是两个不同的原语：

• Tools = model-controlled，模型自己决定何时调用（类似函数调用）
• Resources = application-controlled，由客户端/用户决定何时读取（类似只读文件）

Resources 通过两个 JSON-RPC 方法暴露：resources/list 和 resources/read。Claude Code 把这两个方法分别封装成了两个内置 Tool，让 Claude 模型能够主动发现和读取 MCP Server 暴露的资源。

两个工具的作用

ListMcpResourcesTool

对应 MCP 协议的 resources/list 方法。作用是列举某个 MCP Server 暴露的所有可用资源。返回的每个 resource 包含：

{
  "uri": "file:///logs/app.log",    // 唯一标识
  "name": "Application Logs",       // 人类可读名称
  "description": "...",             // 可选描述
  "mimeType": "text/plain"         // 可选 MIME 类型
}

相当于"先看看菜单上有什么"。

ReadMcpResourceTool

对应 MCP 协议的 resources/read 方法。作用是根据 URI 读取某个具体资源的内容。输入一个 resource URI，返回文本或 base64 二进制内容。

相当于"点了菜单上的某一道菜"。

使用场景举例

场景 1：数据库 Schema 浏览

假设你连接了一个 database MCP server，它把数据库表结构暴露为 resources：

用户: "帮我看看数据库里有哪些表，然后看看 users 表的 schema"

Claude Code 内部流程:
1. 调用 ListMcpResourcesTool → 获得资源列表:
   - db://schema/users  (Users 表结构)
   - db://schema/orders (Orders 表结构)
   - db://schema/products (Products 表结构)

2. 调用 ReadMcpResourceTool(uri="db://schema/users") → 获得:
   CREATE TABLE users (
     id SERIAL PRIMARY KEY,
     name VARCHAR(255),
     email VARCHAR(255) UNIQUE,
     ...
   )

3. 基于读取到的 schema 内容回答用户

场景 2：项目文档/配置读取

一个 Kotlin MCP Server 暴露了 18 个 resources（项目文档、配置文件等）：

用户: "帮我了解这个项目的架构"

Claude Code 内部流程:
1. ListMcpResourcesTool → 发现:
   - docs://architecture.md
   - docs://api-spec.yaml
   - config://application.yml

2. ReadMcpResourceTool(uri="docs://architecture.md") → 读取架构文档内容

3. 综合内容给出架构分析

场景 3：日志/监控数据

用户: "最近有什么错误日志？"

Claude Code 内部流程:
1. ListMcpResourcesTool → 发现:
   - file:///logs/app.log
   - file:///logs/error.log

2. ReadMcpResourceTool(uri="file:///logs/error.log") → 读取错误日志

3. 分析日志内容

与 MCP Tools 的关键区别

这是个容易混淆的点。用你熟悉的类比：

维度	Resources (List/Read)	Tools (Call)
控制方	application/user-controlled	model-controlled
操作类型	只读，获取数据/上下文	可执行，可有副作用
类比	GET 请求 / 读文件	POST 请求 / RPC 调用
Claude Code 中	ListMcpResourcesTool + ReadMcpResourceTool	mcp__serverName__toolName

实际情况

从搜索到的 GitHub Issues 来看，Claude Code 对 Resources 的支持还存在一些问题，比如 HTTP 类型的 MCP Server 的 resources 操作有 bug（Issue #11292），分页支持也还不完善（Issue #3141）。不过 stdio 类型的 Server 的 resources 通常能正常工作。

总结一句话：ListMcpResourcesTool 是"发现有什么数据可读"，ReadMcpResourceTool 是"把某个数据读出来"，它们让 Claude 模型能够主动浏览和获取 MCP Server 暴露的静态/半静态数据源，作为上下文来辅助回答。