Analyzed: March 31, 2026 leak snapshot

​
Web-facing tools

The source-visible web capability split is:
  • WebFetchTool: fetch a specific URL
  • WebSearchTool: search the web
  • WebBrowserTool: richer browser automation, feature-gated
This is a deliberate separation of concerns. Search and fetch solve different context-acquisition problems, and browser automation is riskier than either.

​
Why search and fetch are separate

The model often needs either:
  • discovery: find candidate URLs from a query
  • retrieval: read a concrete page already identified
Using separate tools improves tool selection and keeps schemas smaller than a single overloaded web tool.

​
Permission posture

Web tools are generally lower-risk than shell execution, but they are not free of policy:
  • network-disabled or restricted environments can still block them
  • domain policies can matter
  • browser automation is more sensitive than plain fetch or search
The permission engine treats the backend action and its context, not just the tool name.

​
Browser tool gating

WebBrowserTool is only registered when the WEB_BROWSER_TOOL feature is enabled. That means it can exist in source but be absent in the running build. Do not assume browser automation exists just because the directory is present.

​
MCP comparison

Web tools are first-party built-ins. They are distinct from MCP resources and MCP tools:
  • web tools have first-party execution semantics
  • MCP tools come from connected external servers
  • MCP resources are read-oriented content channels
That distinction matters for approval and trust.