Use Case
Vessel's chat assistant and external MCP harnesses currently discover information by driving the real browser to a search engine page and reading results from the rendered DOM. That fits Vessel's "real browser, human-visible" thesis well for most tasks, but it has costs:
- SERP pages are noisy: cookie banners, ads, layout shifts, JS-driven result rendering
- The agent burns tool calls on
clear_overlays / read_page / scroll just to get to the underlying links
- Some result pages are hostile to Chromium-driven reads (challenge pages, geo-walls)
- For "find me 5 sources about X" intents, the assistant doesn't actually need to see the SERP at all; it just needs the result list
A lightweight, optional web-search tool (not a replacement for browsing) would let the chat assistant skip the SERP and jump straight to ranked results when that's all it needs. The agent can then navigate to a specific result and use the existing browser tools to read it like normal — supervised, visible, and undoable.
Proposed Shape
A new optional tool exposed to the chat assistant (and over MCP, gated on a configured API key):
web_search
- Inputs:
query (string), optional num_results, optional include_domains / exclude_domains, optional category (news, research paper, company, etc.)
- Returns: a typed list of
{ url, title, published_date?, snippet? } results
- The tool only returns metadata — actual page reading still goes through the existing
navigate + read_page flow, so the human still sees what the agent reads
Implementation would use Exa (https://exa.ai), which has a typed JS/TS SDK and supports the filtering options above. The tool would be:
- Disabled by default: only registered if
EXA_API_KEY is set in Settings
- Off the critical path: pure additive; existing browser-based search continues to work unchanged
- Visible to the supervisor: the search call appears in the Dev Tools panel like any other tool call, and any pages the agent then opens are still rendered in a normal tab
Why open an issue first
Per CONTRIBUTING.md, opening an issue before a larger change. I'm happy to draft the PR if this direction is interesting; if it conflicts with the product direction (e.g. you'd rather keep all information acquisition flowing through the visible browser surface), totally understand — would just want to know before writing code.
A few specific questions to scope this:
- Would you want this tool exposed only to the built-in chat assistant, only over MCP for external harnesses, or both?
- Settings already has provider/API-key fields for chat models — would adding
EXA_API_KEY there be the right home, or do you have a preferred place for non-chat provider keys?
- Any preference on naming (
web_search vs. something more specific)?
Disclosure: I work at Exa. Happy to keep this neutral / contribute the implementation either way.
Use Case
Vessel's chat assistant and external MCP harnesses currently discover information by driving the real browser to a search engine page and reading results from the rendered DOM. That fits Vessel's "real browser, human-visible" thesis well for most tasks, but it has costs:
clear_overlays/read_page/scrolljust to get to the underlying linksA lightweight, optional web-search tool (not a replacement for browsing) would let the chat assistant skip the SERP and jump straight to ranked results when that's all it needs. The agent can then
navigateto a specific result and use the existing browser tools to read it like normal — supervised, visible, and undoable.Proposed Shape
A new optional tool exposed to the chat assistant (and over MCP, gated on a configured API key):
web_searchquery(string), optionalnum_results, optionalinclude_domains/exclude_domains, optionalcategory(news, research paper, company, etc.){ url, title, published_date?, snippet? }resultsnavigate+read_pageflow, so the human still sees what the agent readsImplementation would use Exa (https://exa.ai), which has a typed JS/TS SDK and supports the filtering options above. The tool would be:
EXA_API_KEYis set in SettingsWhy open an issue first
Per CONTRIBUTING.md, opening an issue before a larger change. I'm happy to draft the PR if this direction is interesting; if it conflicts with the product direction (e.g. you'd rather keep all information acquisition flowing through the visible browser surface), totally understand — would just want to know before writing code.
A few specific questions to scope this:
EXA_API_KEYthere be the right home, or do you have a preferred place for non-chat provider keys?web_searchvs. something more specific)?Disclosure: I work at Exa. Happy to keep this neutral / contribute the implementation either way.