First off, thanks for open-webSearch — it's become my go-to MCP server for giving Claude and Cursor real-time web search without juggling API keys. The multi-engine approach with Bing, Brave, DuckDuckGo, etc. works great.
The gap I keep hitting
The one engine conspicuously missing is Google. I know Google scraping is a nightmare (CAPTCHAs, IP blocks, constantly changing selectors), which I assume is why it's not in the lineup alongside Bing and Brave. But for many searches — especially technical queries, local results, and recent news — Google's index quality is genuinely better.
Suggestion
Would you consider adding https://serpbase.dev as an optional Google search engine? It's a Google Search Results API that returns structured JSON (title, URL, description, rich snippets) — the same shape as what your existing engines produce. Instead of scraping Google directly, it handles all the CAPTCHA/proxy/rotating-UA complexity server-side.
A key difference from the other engines: serpbase requires an API key. I think this is fine as an opt-in engine — users who need Google results can sign up (they have a free tier), and users who prefer the current keyless experience aren't affected.
Why it fits
- Your result schema already returns
title, url, description per result — serpbase's response maps almost 1:1. The integration surface should be small.
- You already have an engine abstraction layer (adding "google" via serpbase alongside "bing", "brave", etc.) — this is just another engine implementation.
- For users in regions where Bing/Baidu aren't ideal or who want Google's index specifically, this fills the last major search gap.
Happy to help test an integration or put together a draft PR if there's interest. No worries if the API-key requirement makes it a poor fit for the project's philosophy — just figured I'd float the idea since I keep reaching for Google results.
First off, thanks for open-webSearch — it's become my go-to MCP server for giving Claude and Cursor real-time web search without juggling API keys. The multi-engine approach with Bing, Brave, DuckDuckGo, etc. works great.
The gap I keep hitting
The one engine conspicuously missing is Google. I know Google scraping is a nightmare (CAPTCHAs, IP blocks, constantly changing selectors), which I assume is why it's not in the lineup alongside Bing and Brave. But for many searches — especially technical queries, local results, and recent news — Google's index quality is genuinely better.
Suggestion
Would you consider adding https://serpbase.dev as an optional Google search engine? It's a Google Search Results API that returns structured JSON (title, URL, description, rich snippets) — the same shape as what your existing engines produce. Instead of scraping Google directly, it handles all the CAPTCHA/proxy/rotating-UA complexity server-side.
A key difference from the other engines: serpbase requires an API key. I think this is fine as an opt-in engine — users who need Google results can sign up (they have a free tier), and users who prefer the current keyless experience aren't affected.
Why it fits
title,url,descriptionper result — serpbase's response maps almost 1:1. The integration surface should be small.Happy to help test an integration or put together a draft PR if there's interest. No worries if the API-key requirement makes it a poor fit for the project's philosophy — just figured I'd float the idea since I keep reaching for Google results.