WebSearch与WebFetch两个工具分工明确形成搜索 → 抓取的完整流水线下面从多个维度对比核心定位维度WebSearchWebFetch职责发现页面找链接读取页面取内容输入搜索关键词 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与ReadMcpResourceToolClaude 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(uridb://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(uridocs://architecture.md) → 读取架构文档内容 3. 综合内容给出架构分析场景 3日志/监控数据用户: 最近有什么错误日志 Claude Code 内部流程: 1. ListMcpResourcesTool → 发现: - file:///logs/app.log - file:///logs/error.log 2. ReadMcpResourceTool(urifile:///logs/error.log) → 读取错误日志 3. 分析日志内容与 MCP Tools 的关键区别这是个容易混淆的点。用你熟悉的类比维度Resources (List/Read)Tools (Call)控制方application/user-controlledmodel-controlled操作类型只读获取数据/上下文可执行可有副作用类比GET请求 / 读文件POST请求 / RPC 调用Claude Code 中ListMcpResourcesTool ReadMcpResourceToolmcp__serverName__toolName实际情况从搜索到的 GitHub Issues 来看Claude Code 对 Resources 的支持还存在一些问题比如 HTTP 类型的 MCP Server 的 resources 操作有 bugIssue #11292分页支持也还不完善Issue #3141。不过 stdio 类型的 Server 的 resources 通常能正常工作。总结一句话ListMcpResourcesTool 是发现有什么数据可读ReadMcpResourceTool 是把某个数据读出来它们让 Claude 模型能够主动浏览和获取 MCP Server 暴露的静态/半静态数据源作为上下文来辅助回答。
claude code的常用内置工具
WebSearch与WebFetch两个工具分工明确形成搜索 → 抓取的完整流水线下面从多个维度对比核心定位维度WebSearchWebFetch职责发现页面找链接读取页面取内容输入搜索关键词 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与ReadMcpResourceToolClaude 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(uridb://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(uridocs://architecture.md) → 读取架构文档内容 3. 综合内容给出架构分析场景 3日志/监控数据用户: 最近有什么错误日志 Claude Code 内部流程: 1. ListMcpResourcesTool → 发现: - file:///logs/app.log - file:///logs/error.log 2. ReadMcpResourceTool(urifile:///logs/error.log) → 读取错误日志 3. 分析日志内容与 MCP Tools 的关键区别这是个容易混淆的点。用你熟悉的类比维度Resources (List/Read)Tools (Call)控制方application/user-controlledmodel-controlled操作类型只读获取数据/上下文可执行可有副作用类比GET请求 / 读文件POST请求 / RPC 调用Claude Code 中ListMcpResourcesTool ReadMcpResourceToolmcp__serverName__toolName实际情况从搜索到的 GitHub Issues 来看Claude Code 对 Resources 的支持还存在一些问题比如 HTTP 类型的 MCP Server 的 resources 操作有 bugIssue #11292分页支持也还不完善Issue #3141。不过 stdio 类型的 Server 的 resources 通常能正常工作。总结一句话ListMcpResourcesTool 是发现有什么数据可读ReadMcpResourceTool 是把某个数据读出来它们让 Claude 模型能够主动浏览和获取 MCP Server 暴露的静态/半静态数据源作为上下文来辅助回答。
