[georgeatparallel]

Fresh Open WebUI installations can search the web with Parallel Search MCP, with no account, API key, or local bridge needed. Anonymous searches use Fast mode.

The launcher uses Parallel when no Brave key is configured. Existing BRAVE_API_KEY or .brave_key configurations keep Brave selected, including its news and summarizer tools. Set BONSAI_WEB_SEARCH=parallel|brave|none to select or disable the connection. Existing model tool selections and access grants survive re-seeding; existing models can select the available server from the chat tool menu.

For general web search, Artificial Analysis's Search API benchmark reports DeepSearchQA F1 of 0.802 for Parallel Fast and 0.623 for Brave Search. Source.

I work at Parallel.

[khosravipasha]

🤖 Reviewing on behalf of the maintainers

Thanks for contributing this! Keyless search could be useful for the demo, and preserving existing tool selections and access grants is a good improvement. A few points before merging:

• Please isolate PATH in the MCP tests and add a subprocess timeout. The “bridge missing” test inherited my actual PATH, found the installed Brave bridge, launched it, and hung at wait. I stopped the test and bridge; all 15 tests passed when rerun with an isolated PATH. The tests should guarantee that behavior themselves.
• Is the legacy Search MCP endpoint intentional for this integration? Your docs recommend the newer unified MCP for new installs. Keeping the smaller search-only endpoint may make sense, but please confirm it will remain supported for this demo.
• For new model records, this automatically attaches remote search. I would lean toward making it available but opt-in; if we keep it attached by default, please make that clear at startup, including that search queries go to Parallel and that users can disable it with BONSAI_WEB_SEARCH=none. It also adds tool-schema overhead to the prompt.

Please also confirm a live search round-trip with our pinned Open WebUI version, including how anonymous rate-limit errors are presented. My validation covered the isolated tests, not a live Open WebUI search.

No need to make this elaborate; a small test fix and clarification of the endpoint/default behavior should keep it manageable. Thanks again!

[georgeatparallel]

Thanks for the careful review, @khosravipasha. I pushed afcf561 and rebased onto current main.

• Test isolation: the MCP tests no longer inherit the host PATH. Each test runs with only its fixture dir plus symlinks to the commands the preset actually calls, and the preset runs in its own process group with a 30s timeout that kills the group and fails the test. There's a new test that puts a sleeping brave-search-mcp-server on the real PATH and asserts it is never found or started. python3 -m unittest discover -s tests passes (61 tests).
• Endpoint: yes, intentional. search.parallel.ai/mcp is free and keyless with just web_search and web_fetch, so the prompt overhead stays small. Our docs call it legacy but it remains supported for existing clients. I added a comment in mcp_servers.sh and a short "Why this endpoint" note in TOOLS.md.
• Opt-in: DEFAULT_MCP_TOOL_IDS is now empty, so new model records get no MCP server attached and nothing goes to a search provider until a user picks it from the chat tool menu. Saved toolIds and access grants are still preserved on re-seed. The launcher also prints that queries go to parallel.ai and that BONSAI_WEB_SEARCH=none removes it. One side effect is that Brave is now opt-in too. Happy to keep auto-attaching Brave when a key is configured if you'd prefer.
• Live check with open-webui 0.10.2: Open WebUI loaded the connection from mcp_servers.sh, its tool server verify endpoint listed both tools, and it rendered them into the model payload as parallel_web_search / parallel_web_fetch. Its own MCPClient ran a real web_search and got live results. I didn't do a full browser chat with a real Bonsai model, so the model's own decision to call the tool is the one part I didn't verify.
• Rate limits: when I forced one with a burst of concurrent anonymous calls, it came back as a JSON-RPC error inside an HTTP 200. Open WebUI's middleware catches it and shows the plain message as the tool result ("You've hit the free-tier rate limit for Parallel Search MCP. To continue with higher limits, add your own API key..."), so the user and model see an explanation rather than a crash or empty result. Single searches never hit it.