Optional native Parallel Search MCP web-search provider #2295

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• Please do not modify this template :) and fill in all the required fields.

Primary Feature Area

AI-Powered Capabilities (Web Search, Knowledge Base Search)

1. Feature Description

I'd like to contribute Parallel as an optional native web-search provider, using our free, keyless Search MCP at https://search.parallel.ai/mcp. Anonymous searches use Fast mode and have free-tier limits.

Users would select a Parallel provider through Refly's existing webSearch provider configuration and save its ID in preferences.webSearch.providerId. The normal web_search operation would then call Parallel and return titles, URLs and excerpts through the existing result and citation flow. This would be a native backend, rather than a separate set of MCP tools.

SearXNG would remain the no-provider fallback. Saved Serper/SearXNG choices, global-provider selection and WEB_SEARCH_ENABLED would keep their current behavior.

2. Use Case & Problem Statement

Refly's canonical search service currently supports Serper and SearXNG. Parallel would give users another way to run web research without obtaining a search API key or running their own search service. They'd still need to choose it explicitly.

That would help with research tasks that need useful source excerpts and citations, while keeping search inside the workflow Refly already uses.

3. Expected Benefits

The main benefit is a hosted, keyless search option that feeds the normal search and citation path. Parallel's Fast API is evaluated in Artificial Analysis's DeepSearchQA results and time per task. DeepSearchQA tests broad research and answer completeness; time per task combines measured search time with derived model time. These are provider benchmarks, not measurements of a Refly integration. I haven't found a comparable SearXNG result there, so I'm not claiming a benchmark advantage over Refly's default.

4. Additional Context

I traced this against 71f8b875c8751e881776749d8ed7a74383b65fb0. The proposed change would add a small web-search adapter under apps/api/src/utils/web-search, register it in SearchService.webSearch, and add the provider metadata and connection validation needed for the existing configuration path. Refly already has an HTTP MCP client we can reuse.

The old search-provider dropdown doesn't appear to be mounted by the current Settings UI. Would you prefer this backend to use the supported provider/preferences APIs first, or should the contribution also expose native search selection in Settings?

Queries and any supplied search objective/context would go to Parallel once selected. I'd document that and preserve existing limits, locale/batch handling and error behavior. Proposed validation would cover saved-provider selection, a real keyless MCP search, result/citation mapping and unchanged SearXNG/Serper routing. No implementation or integration tests have run yet.

Btw - I'm a devrel engineer at Parallel. Your contribution guide asks for a team go-ahead before feature work, so I'm opening this proposal first. Is this optional native provider contribution a fit?

5. Contribution Interest

• I am interested in contributing to this feature (coding, design, testing, or documentation)
• I would be willing to provide feedback during the feature's development