Describe the feature
Onlook's web_search tool currently calls Exa directly, so a self-hosted instance needs EXA_API_KEY before the assistant can search the web. Would you be open to an optional Parallel Search MCP backend for that same tool? It would let people try web search through the free, keyless MCP endpoint without changing the Exa default.
I'd add the choice in the server's existing webSearch route and environment config, then map MCP results into the current WebSearchResult shape so the chat tool and source display keep working. Queries would go to Parallel when that backend is selected. The anonymous endpoint has lower rate limits, which I'd document.
There's one compatibility detail I'd like your take on before coding: Onlook's tool accepts allowed_domains and blocked_domains, but anonymous Parallel MCP doesn't offer hard per-call domain filters. I wouldn't silently ignore those constraints. My proposed behavior is a clear unsupported-filter error when Parallel is selected and either filter is supplied. Does that fit how you expect the tool to be used, or would you prefer a different approach?
For context, Artificial Analysis's DeepSearchQA chart currently shows Parallel Fast at 80 F1 and Exa Auto at 78. Its time-per-task chart shows 19.4s versus 33.3s. That's their benchmark harness, not a measurement of Onlook, but it's why I think this is worth testing in the existing search path.
Btw - I'm a devrel engineer at Parallel. If this direction sounds useful, I can send a small PR with the route, docs, and tests after we settle the filter behavior.
Describe the feature
Onlook's
web_searchtool currently calls Exa directly, so a self-hosted instance needsEXA_API_KEYbefore the assistant can search the web. Would you be open to an optional Parallel Search MCP backend for that same tool? It would let people try web search through the free, keyless MCP endpoint without changing the Exa default.I'd add the choice in the server's existing
webSearchroute and environment config, then map MCP results into the currentWebSearchResultshape so the chat tool and source display keep working. Queries would go to Parallel when that backend is selected. The anonymous endpoint has lower rate limits, which I'd document.There's one compatibility detail I'd like your take on before coding: Onlook's tool accepts
allowed_domainsandblocked_domains, but anonymous Parallel MCP doesn't offer hard per-call domain filters. I wouldn't silently ignore those constraints. My proposed behavior is a clear unsupported-filter error when Parallel is selected and either filter is supplied. Does that fit how you expect the tool to be used, or would you prefer a different approach?For context, Artificial Analysis's DeepSearchQA chart currently shows Parallel Fast at 80 F1 and Exa Auto at 78. Its time-per-task chart shows 19.4s versus 33.3s. That's their benchmark harness, not a measurement of Onlook, but it's why I think this is worth testing in the existing search path.
Btw - I'm a devrel engineer at Parallel. If this direction sounds useful, I can send a small PR with the route, docs, and tests after we settle the filter behavior.