Live web search through configured OpenAI-compatible models, returning answers with numbered sources via single-model or hybrid consensus.
Run natural-language web searches or research questions with multi_api_web_search (or the web_search alias exposed in the schema).
Select a configured model/engine, or use hybrid for multi-engine consensus.
Limit returned sources from 1 to 30 (default 15).
Receive a plain-text answer plus a numbered source list.
Rely on configured defaults/fallbacks and per-model search modes behind the scenes.
Provides live web search through OpenAI-compatible API endpoints, using configured models to perform searches in native or tool mode, with optional hybrid multi-model consensus, fallback models, and merged source lists.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@multi-api-web-search Search for the latest breakthroughs in fusion energy with cited sources"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Live web search for MCP clients through any OpenAI-compatible endpoint. A built-in doctor benchmarks your endpoint's models, picks the best search mode for each one, and writes the config for you.
Per-model search mode: each model runs either in native mode (the model searches silently) or tool mode (an explicit web_search tool, usually with more citations). The doctor measures both and saves the faster or more accurate one.
Hybrid search: ask 2+ models in parallel, get their answers side by side plus one merged, deduplicated source list.
Never hangs, never cuts a working answer: requests are streamed. A model gets TIMEOUT_MS (25 s) to search and write its first word; a request that stays silent is dropped and sent once more. After that it may keep writing as long as text keeps arriving, and it is only cut after IDLE_TIMEOUT_MS of silence. If tool mode returns a gateway error, the same call retries once in native mode.
Fallback model: retry with a second model when the default one fails.
Related MCP server: qsearch
git clone https://github.com/Peteroooooooo/multi-api-web-search-mcp.git
cd multi-api-web-search-mcp
npm installcp .env.example .envFill in the two required lines in .env:
MULTI_WEB_SEARCH_BASE_URL=https://api.your-provider.com/v1
MULTI_WEB_SEARCH_API_KEY=sk-your-key-herenpm run setupOn Windows you can double-click doctor.bat instead. It creates .env and opens it in Notepad if the file is missing, then asks whether setup should pick the winner (Auto) or show you the leaderboard (Manual).
Setup first lists every model on your endpoint as a checklist, because most endpoints serve many models that can't search, and only you know which are worth the requests. Move with ↑/↓, tick with Space, press Tab to tick everything shown, type to filter (gemini shows only Gemini models), and confirm with Enter. Models already in your .env start ticked. You can also skip the menu with -- --models a,b, or test everything with -- --all. From there setup decides by itself: it tests each chosen model in both search modes, then re-checks the best 4 on two more questions. All answers are graded against nodejs.org at run time, so the test never goes stale. The most accurate model wins. Among equally accurate models, one that is at least 25% faster wins; otherwise the one with more sources wins. The winner becomes the default model, and the runner-up becomes the fallback and the second hybrid model. Each model's search mode is saved, and so is reasoning_effort=low if the chosen models accept it. Each model costs 2 requests, plus 2 more for each of the top 4. If .env already has MULTI_WEB_SEARCH_MODEL=hybrid, setup keeps hybrid as the default and fills in the two best models. Add -- --hybrid or -- --single to choose explicitly.
To see the full leaderboard and choose the default yourself, run npm run doctor (or pick Manual in doctor.bat). It starts with the same checklist, and afterwards you tick one model for the default or two or more for hybrid.
The server reads .env itself, so the client config only needs the path. The doctor prints this command with your real path:
claude mcp add -s user multi-api-web-search -- node "/path/to/multi-api-web-search-mcp/src/index.js"Other clients (Cursor .cursor/mcp.json, etc.):
{
"mcpServers": {
"multi-api-web-search": {
"command": "node",
"args": ["/path/to/multi-api-web-search-mcp/src/index.js"]
}
}
}Variables set in the client's env block override .env. Leave them out unless you want a per-client override. Otherwise, settings the doctor saves won't take effect.
Variable | Required | Default | Description |
| Yes | - | OpenAI-compatible endpoint base URL |
| Yes | - | API key for that endpoint |
| No | - | Default model, or |
| No | - | Comma-separated models used by |
| No | - | Models that always use the explicit |
| No | - | Models that never get the tool |
| No | - | Model to retry with when the default fails |
| No |
| Max wait for the first word of the answer, per attempt. The model searches during this time; healthy answers start in 3-12 s. A request that stays silent this long is dropped and sent once more, which usually reaches a working upstream account. Requests are streamed, so once text starts the call keeps going while it arrives, up to 180 s in total |
| No |
| After output starts, how long a silent stream may stay quiet before it is cut. Grok can pause about 15 s mid-answer to run another search. A cut stream returns what it has, marked as possibly cut off |
| No | not sent |
|
| No | none | Default |
| No | off |
|
FORCE_TOOL / FORCE_NATIVE entries match an exact model name or a fragment (gemini matches gemini-3.8-flash). An exact name beats a fragment. Models in neither list use tool mode if their name contains grok, gpt or search.
multi_api_web_search returns an answer and a numbered source list as plain text.
query (string, required): search query or question.
model (string, optional): a model name or hybrid. The tool description lists your configured models.
max_sources (number, optional): 1-30, default 15.
focus (precise | broad | normal, optional): picks the built-in instructions sent to the model. broad asks for wide exploration: several searches from different angles and source types, many distinct items grouped by direction, and up to 30 sources. In tests with Gemini, broad cited 35 arXiv papers across 6 research answers. All 35 existed, and about 32 matched their description; the default prompt cited 2. broad answers run about 5x longer, so it is meant for open-ended questions, not single facts. precise asks for one current fact, checked against the newest primary source. With Gemini it measured the same as the default prompt. Leave focus empty, or pass normal, for a short balanced answer. Every prompt includes today's date.
reasoning_effort (low | medium | high, optional): overrides the default for one call.
No temperature is sent, so each model uses its own default. Gemini 3 models are tuned for their default of 1.0. A model that returns an empty answer counts as failed, so the fallback model or the other hybrid models take over.
npm testThe tests run against a local mock endpoint. No API key needed.
MIT
Multi-API Web Search: Live internet search across your configured API models. Supports single model or multi-engine consensus ('hybrid').
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional search engine mode or model name (e.g. 'gemini', 'grok', 'fast', 'hybrid' for multi-engine consensus). | |
| query | Yes | Search query or research question in natural language. | |
| max_sources | No | Max number of sources to include (1-30, default 15). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does convey that this performs live external searches and can aggregate multiple engines into a consensus, but it omits operational traits like rate limits, failure behavior, and unconfigured model handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. The core operation is front-loaded, and the second sentence adds meaningful scope about single-model and hybrid consensus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a sibling tool to differentiate from, the description is incomplete. It does not clarify default model behavior, expected result shape, or when to use this tool instead of web_search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no real parameter semantics beyond restating the hybrid mode that is already described in the model parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: live internet search across configured API models, with an optional hybrid consensus mode. It is clear and distinct from a vague generic search, but it does not explicitly position itself against the sibling web_search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over web_search, nor when to prefer single-model vs hybrid mode. The mention of hybrid implies a capability but does not provide selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-API Web Search: Live internet search across your configured API models. Supports single model or multi-engine consensus ('hybrid').
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional search engine mode or model name (e.g. 'gemini', 'grok', 'fast', 'hybrid' for multi-engine consensus). | |
| query | Yes | Search query or research question in natural language. | |
| max_sources | No | Max number of sources to include (1-30, default 15). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states that the search is live and may span multiple configured API models, but it does not describe result format, failure behavior, rate limits, or what hybrid consensus actually returns. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It communicates the core capability efficiently, though it omits deeper usage guidance that would have made it more complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter search tool, the minimum invocation is well covered by the schema and the live-search statement. However, with no output schema and no annotations, the absence of result-format details and the lack of distinction from the sibling tool leave notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters adequately. The description adds the idea of hybrid consensus but does not meaningfully extend parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a live web search action and explains single-model vs hybrid consensus modes. It names the resource and action, making the tool's purpose understandable. However, it doesn't distinguish this tool from sibling multi_api_web_search, especially since the description itself says 'Multi-API'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use web_search versus multi_api_web_search, and the sibling is not mentioned. The only usage signal is that 'hybrid' enables multi-engine consensus, which implies a mode choice but not when this tool should be preferred over an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.3.0multi_api_web_searchweb_searchScored across 2 tools
Both tools have the exact same description and purpose, differing only in the name prefix. An agent cannot reliably choose between them because they appear to be identical duplicates.
Both names use snake_case, but 'web_search' and 'multi_api_web_search' are near-duplicates with no clear convention. The prefixed variant is inconsistent with the generic one, making the naming feel redundant rather than patterned.
Two tools exist but they appear to serve the exact same function. One tool would be appropriate for this simple search server; the extra tool is redundant and does not earn its place.
For a web search server, the tool surface covers the core capability of performing live internet searches. No additional operations like create, update, or delete are relevant to this domain, so there are no obvious gaps.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Scrape, crawl and search the web for AI agents via MCP.
Free web search for AI agents. No API key required. Hosted MCP in active development.
