Optional keyless Parallel provider for web_search

[georgeatparallel]

Hi Oli, I’m George from Parallel. Would you be open to an optional Parallel provider for the existing web_search tool?

Users would select parallel through interactions.chat.tools.web_search.opts.adapter. The normal web_search call would then use our free Search MCP at https://search.parallel.ai/mcp and return titles, URLs, and excerpts in CodeCompanion’s existing attachment format. Anonymous searches use Fast mode with lower rate limits and need no API key.

Tavily would remain the default, and existing DuckDuckGo and Jina configurations would keep working. The selection would power the canonical web_search operation and use its existing result output.

For context, Artificial Analysis currently reports Parallel Fast at 80 DeepSearchQA F1 and 18.4 seconds per task in its quality and time per task charts. These are search-provider benchmark results, not measurements of CodeCompanion or a promise of the same speed here.

CodeCompanion currently uses stdio for MCP, so I’d reuse that client with an mcp-remote bridge. The work would need a small dispatch boundary in web_search.lua because the current path always calls an HTTP adapter. I’d keep MCP connection lifecycle, errors, timeouts, and chat cancellation in the existing MCP code, and document the Node/bridge requirement. Queries and any supplied search context or domains would go to Parallel; selecting the provider would enable that transfer when the agent calls the tool.

Before submitting a PR, I’d validate the configured provider through a real Neovim tool call, result attachments, domain handling, errors and cancellation, and verify the project identifier on outgoing Search requests. Existing provider behavior would also need regression checks. No implementation or runtime testing has been done yet.

Does that fit the direction you want for the built-in search tool?

[olimorris]

Hey George. Defo send over a PR and I'll take a look 👍