Add an opt-in Parallel Search MCP provider

[georgeatparallel]

What changed

Adds an opt-in Parallel Search MCP backend to FrontierAgent's existing web_search provider path. Setting WEB_SEARCH_PROVIDER=parallel selects the free endpoint without a Parallel API key. Both original and aligned native search implementations use it.

Serper remains the implicit provider. Its current missing-key behavior stays the same, and Parallel errors do not fall back silently. The anonymous MCP supports up to 10 results per query; larger counts and unsupported custom region, language, or time filters return a clear message to use Serper. Existing search result filters and closed-book profile switches remain in effect. web_fetch keeps its existing provider.

Setup

Set WEB_SEARCH_PROVIDER=parallel in the project .env or the existing user env file. The Parallel Search MCP documentation describes the anonymous endpoint. Setting the value to serper restores the current provider.

Validation

• The original and aligned workflow profiles each loaded the saved Parallel selection and ran two search queries through the live anonymous MCP endpoint.
• Both profiles returned results for both queries, and the agent loop produced a source-linked final answer.
• The isolated run had no Parallel or Serper key. All 12 MCP requests carried the truthful FrontierAgent/0.1.0 User-Agent and no Authorization header.
• uv run pytest -q: 1,804 passed, 1 skipped, 18 existing pytest marker warnings.
• uv run pytest tests/test_parallel_search.py apodex/tests/test_config_preflight.py apodex/tests/test_userenv.py -q: 47 passed, 1 skipped.
• uv run ruff check frontier_agent/ apodex/ benchmarks/ workflows/ plugins/ deploy/ tools/ scripts/: passed.
• uv run pyright: 0 errors, 0 warnings, 0 informations.
• Import smoke, symbol checks, lazy export checks, and git diff --check: passed.

Affiliation

I work at Parallel.

Search benchmarks

These links show the current filtered charts. This PR makes no benchmark claims.

• DeepSearchQA
• Time per Task

[zhanghanduo]

Thanks for adding this integration and for the thorough validation! I tried the new provider path and noticed two small issues:

• In _parallel_search.py, results are sliced to num_results before the existing domain filters and URL deduplication run. For example, requesting one result can return only a “blocked results” message when the first result is filtered out, even though the response contains a useful second result. Could we apply the limit after filtering and deduplication so those remaining results can still be used?
• The live Parallel response uses publish_date, while _normalise_result() currently reads published_date or date. This drops the publication dates from the aligned search output. Could we include publish_date in that mapping?

The 48 focused tests passed locally; I reproduced these two cases separately. Thanks again for the contribution!

[grp06]

Thanks for catching both! Fixed in edc0847. Both search paths now apply the per-query limit after filtering and URL deduplication, and publication dates read publish_date with the existing fallbacks preserved. Added regression coverage for filtered results, duplicate URLs, multi-query limits, and date mapping. All 78 relevant tests and lint pass.