GroundRoute
GroundRoute provides a single search tool that routes web search queries across multiple engines (Serper, Brave, Exa, Tavily, Firecrawl, and Perplexity), handling caching, failover, and cost optimization automatically.
Core capabilities:
Multi-engine routing — Automatically selects the best-value engine (cheapest that clears a quality bar) for each query, with automatic failover if an engine degrades.
Search modes — Supports
auto,web,news,academic,answer(AI-synthesized answer with citations), andpage(full page content via Firecrawl).Rich search parameters — Control query, max results (1–50), freshness (
fresh,semi,static), domain filters, language (ISO 639-1), and country (ISO 3166-1).Caching — Repeated queries are served from cache (exact_private, exact_pooled, or semantic) to reduce cost.
Structured results — Returns URL, title, snippet, full content (where available), publish date, and the source engine used.
Transparency metadata — Each response includes request ID, cache tier, degraded-path status, and exact billed cost in USD.
Integration — Connects via MCP (HTTP or stdio) to any compatible client (Claude, Cursor, VS Code, etc.), with support for bring-your-own-keys (BYOK) and self-hosting via Docker.
Routes search queries to the Brave search engine, providing web search results.
Routes search queries to the Perplexity AI search engine, providing web search and answer capabilities.
Give your AI agent web search across 6 engines through one MCP
searchtool. Hosted. Routed. Cached.
Why GroundRoute
One tool, six engines. Serper, Brave, Exa, Tavily, Firecrawl, Perplexity, behind a single
searchcall. Stop wiring up six APIs, six SDKs, six billing portals.Never more than going direct. Gain-share pricing: you keep ~half of every cache saving, GroundRoute keeps ~half. On a miss, you just pay the engine. BYOK supported.
Routing, caching, failover, on by default. Each query goes to the cheapest engine that clears a quality bar. Repeats serve from cache. If an engine degrades, we fall back automatically. No agent code changes.
Related MCP server: entroute
See it work (5 seconds)
A call to the search tool:
{
"name": "search",
"arguments": { "query": "what is RAGflow", "max_results": 3 }
}The response (trimmed):
{
"results": [
{
"url": "https://ragflow.io/docs/",
"title": "Quickstart - RAGFlow",
"snippet": "RAGFlow is an open-source RAG engine based on deep document understanding...",
"source_engine": "serper"
},
{
"url": "https://github.com/infiniflow/ragflow",
"title": "RAGFlow is a leading open-source Retrieval-Augmented Generation engine",
"snippet": "RAGFlow is a leading open-source Retrieval-Augmented Generation (RAG) engine...",
"source_engine": "serper"
}
],
"meta": {
"request_id": "req_abc123",
"cache_tier": "miss",
"degraded": false,
"cost_usd": 0.0021
}
}source_engine tells you which engine answered. meta exposes the cache tier and billed cost per call.
Benchmarked, not just shipped
We ran 170 real agent queries across all 6 engines, judged by an LLM, to map cost vs. quality per query class. Full methodology and per-engine results: State of AI Search.
Install
The hosted endpoint is https://api.groundroute.ai/mcp (streamable-HTTP). Get an API key at groundroute.ai/keys.
Claude Desktop / Claude Code, add to your MCP config:
{
"mcpServers": {
"groundroute": {
"type": "http",
"url": "https://api.groundroute.ai/mcp",
"headers": { "Authorization": "Bearer gr_YOUR_KEY" }
}
}
}Cursor, ~/.cursor/mcp.json:
{ "mcpServers": { "groundroute": { "url": "https://api.groundroute.ai/mcp",
"headers": { "Authorization": "Bearer gr_YOUR_KEY" } } } }VS Code (native MCP / Continue), .vscode/mcp.json:
{ "servers": { "groundroute": { "type": "http", "url": "https://api.groundroute.ai/mcp",
"headers": { "Authorization": "Bearer gr_YOUR_KEY" } } } }Local / stdio-only clients, bridge stdio to HTTP with mcp-remote:
{ "mcpServers": { "groundroute": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://api.groundroute.ai/mcp", "--header", "Authorization:Bearer gr_YOUR_KEY"]
} } }Run this repo's stdio server (optional)
This repo also ships a small native stdio MCP server (server.py) that forwards to the hosted API, useful for stdio-only clients or containerized runs.
pip install -r requirements.txt
GROUNDROUTE_API_KEY=gr_YOUR_KEY python server.pyOr with Docker:
docker build -t groundroute-mcp .
docker run -i -e GROUNDROUTE_API_KEY=gr_YOUR_KEY groundroute-mcpIntrospection (tool discovery) works with no key; running a search requires GROUNDROUTE_API_KEY (get one at https://groundroute.ai/keys).
The search tool
Param | Type | Notes |
| string | required |
| enum |
|
| integer | default 10, max 50 |
| enum |
|
| string[] | include-only domain filter, e.g. |
| string | ISO 639-1 language code, e.g. |
| string | ISO 3166-1 alpha-2 country code, e.g. |
Returns a structured result: ranked results (url / title / snippet / content / source_engine / published_at), an optional synthesized answer with citations (answer mode), and meta (request_id / cache_tier / degraded / cost_usd). Routed, cached, and reliable.
How it works
One endpoint in front of many search engines, with price-led routing, caching, failover, and usage governance. See the docs and the State of AI Search benchmark (170 real agent queries across all 6 engines).
Links
Homepage: https://groundroute.ai
Get a key: https://groundroute.ai/keys
Playground (try without installing): https://groundroute.ai/playground
registry-manifest.json in this repo is the listing manifest for MCP registries.
Available Tools
1 toolsearchWeb SearchARead-onlyInspect
Search the live web via GroundRoute.
Routes the query to the best-value engine across Serper, Brave, Exa, Tavily, Firecrawl, and Perplexity (price-led — the cheapest engine that clears a quality bar), serving cache hits when available and failing over automatically. Returns ranked results, an optional synthesized answer with citations (answer mode), and routing/cache/billing metadata. Use it for any current-information, documentation, news, API, or research lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query. | |
| mode | No | Search mode: 'auto' (GroundRoute classifies and picks the engine), or force one of 'web', 'news', 'academic', 'answer' (synthesized answer + citations), or 'page' (fetch full page content). | auto |
| max_results | No | Maximum number of results to return. | |
| freshness | No | Recency filter: 'fresh' (last day/week), 'semi' (last month), or 'static' (timeless). Omit to let GroundRoute auto-detect from the query. | |
| domains | No | Restrict results to these domains (include-only), e.g. ['arxiv.org']. | |
| lang | No | ISO 639-1 language code to bias results, e.g. 'en'. | |
| country | No | ISO 3166-1 alpha-2 country code to bias results, e.g. 'us'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Ranked search results. |
| answer | No | Synthesized answer when the query warrants one; else null. |
| citations | No | Sources backing the answer. |
| meta | Yes | Routing/cache/billing metadata for the call. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds significant behavioral context: routing to cheapest quality engine, cache hits, automatic failover, and metadata in response. No contradictions; it enriches understanding beyond annotations.
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 four sentences, front-loaded with the core purpose. Every sentence adds unique information: the engine orchestration, the response shape, and use cases. No redundancy or unnecessary words.
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 the complexity of the tool (7 parameters, multiple engines, output schema present), the description covers key aspects: what it does, how it routes, what it returns (including metadata), and when to use it. The output schema is noted in context, so return values are covered. Complete and self-sufficient.
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 baseline is 3. The description adds value by explaining the routing logic for 'mode' and auto-detection for 'freshness'. It clarifies how parameters interact with GroundRoute's decision-making, which goes beyond the schema's individual descriptions.
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 states it searches the live web via GroundRoute, with specific verb and resource. It explains the multi-engine routing logic, distinguishing it from a simple search. No siblings exist, but the description is self-contained and precise.
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?
The description explicitly lists use cases: current-information, documentation, news, API, or research lookup. It provides context on when to use the tool, but no exclusions or alternatives since no siblings. The usage guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
search
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion between tools.
With a single tool, naming is trivially consistent; 'search' is a clear and appropriate verb.
One tool feels thin for a search server, though a single search operation can be sufficient. The server would benefit from additional tools like fetching cached results or site-specific searches.
The search tool covers the primary information retrieval need, but lacks explicit support for retrieving full content or managing search history. Minor gaps exist, but agents can work around them.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Agent-native search engine with live web research optimized for AI agents.
The best web search for your AI Agent
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Related MCP Servers
- AlicenseBqualityAmaintenanceOne endpoint, five search providers. Search broker for AI agents with automatic fallback, RRF ranking, and budget enforcement. The LiteLLM of web search.135MIT
- AlicenseNot gradedqualityDmaintenanceEnables web search for AI agents with pay-per-search in USDC, no API keys needed.MIT
- AlicenseNot gradedqualityCmaintenanceWeb search, clean page reading & one-call research dossiers for AI agents. No API key — your agent does the synthesis.93MIT
- AlicenseAqualityAmaintenanceEnables AI agents to perform web searches, fetch and extract page content, and crawl sites with caching, rate limiting, and robots.txt compliance, all without needing API keys.11MIT