Summary
The search_engines parameter (CLI --search-engines and MCP search_engines) is declared but never consumed — passing it has no effect on which engines run.
Repro
CLI (wigolo 0.2.1, npm latest):
wigolo search "gold price" --search-engines=duckduckgo,wikipedia
# Search: "gold price" (9 results, 9526ms, engines: bing) ← bing still used, flag ignored
MCP (same version, via search_engines: ["duckduckgo", "wikipedia"]):
"engines_used": ["bing"] ← parameter ignored
Also tried --search-engines=duckduckgo (single value) — same result.
Source evidence (current main branch)
src/server/tool-schemas.ts:144 — parameter declared in the MCP schema:
search_engines: { type: 'array', items: { type: 'string' }, description: 'Override engine selection' }
- Help text advertises it:
--search-engines=a,b Override engine selection
- Zero consumers —
grep -rn "search_engines|searchEngines" src/ shows only the schema declaration and internal engine-list variables (src/cli/shell.ts, src/daemon/rest/dispatch.ts). Nothing reads the parameter and passes it to handleSearch.
- Engine selection is instead hard-coded in
src/search/core/core-provider.ts (intent/vertical auto-dispatch: bing, duckduckgo, wikipedia, marginalia, mojeek, ...). src/cli/tool-run.ts seeds [new DuckDuckGoEngine(), new BingEngine()] directly for headless runs.
Why it matters
Users cannot exclude specific engines. Concrete case: the Bing engine returns noisy dictionary/currency/visa results for ambiguous queries (e.g. "US ISM manufacturing PMI" — the "US" token is interpreted as USD/visa; verified via direct proxied request to bing.com, so it's Bing's semantics, not a network issue). The only workaround today is post-hoc: detect the noise and re-search elsewhere.
Expected behavior
Either:
- Make the parameter actually work — pass the engine allowlist through to the core orchestrator (override the vertical auto-dispatch), or
- Remove it from the help text and MCP schema until implemented.
Environment
- wigolo 0.2.1 (npm latest, 2026-07-19); also present on current main (clone date 2026-08-14)
- Windows 11
Summary
The
search_enginesparameter (CLI--search-enginesand MCPsearch_engines) is declared but never consumed — passing it has no effect on which engines run.Repro
CLI (wigolo 0.2.1, npm latest):
MCP (same version, via
search_engines: ["duckduckgo", "wikipedia"]):Also tried
--search-engines=duckduckgo(single value) — same result.Source evidence (current main branch)
src/server/tool-schemas.ts:144— parameter declared in the MCP schema:search_engines: { type: 'array', items: { type: 'string' }, description: 'Override engine selection' }--search-engines=a,b Override engine selectiongrep -rn "search_engines|searchEngines" src/shows only the schema declaration and internal engine-list variables (src/cli/shell.ts,src/daemon/rest/dispatch.ts). Nothing reads the parameter and passes it tohandleSearch.src/search/core/core-provider.ts(intent/vertical auto-dispatch: bing, duckduckgo, wikipedia, marginalia, mojeek, ...).src/cli/tool-run.tsseeds[new DuckDuckGoEngine(), new BingEngine()]directly for headless runs.Why it matters
Users cannot exclude specific engines. Concrete case: the Bing engine returns noisy dictionary/currency/visa results for ambiguous queries (e.g.
"US ISM manufacturing PMI"— the "US" token is interpreted as USD/visa; verified via direct proxied request to bing.com, so it's Bing's semantics, not a network issue). The only workaround today is post-hoc: detect the noise and re-search elsewhere.Expected behavior
Either:
Environment