serpent
serpent
Un backend de metabúsqueda de código abierto creado para flujos de trabajo de agentes de IA / MCP.
Agrega resultados de múltiples motores de búsqueda, devuelve un esquema unificado y expone tanto una API HTTP estándar como un servidor MCP que los agentes LLM pueden llamar directamente.
Por qué existe esto
La mayoría de los agregadores de búsqueda están diseñados para una salida legible por humanos: páginas HTML, tarjetas de resultados, interfaces de paginación. Cuando un agente LLM necesita buscar en la web, necesita algo diferente: JSON estructurado, nombres de campo estables, resultados concurrentes de múltiples fuentes y un manejo de errores predecible.
serpent está diseñado para ese caso de uso. No es un clon de SearXNG.
Posicionamiento
Backend de metabúsqueda amigable para agentes
Pasarela de búsqueda centrada en MCP para flujos de trabajo de LLM
API de búsqueda estructurada diseñada para pipelines de IA
Proveedores compatibles
Google no se rastrea directamente. La razón es práctica: las medidas anti-bot de Google hacen que el rastreo autohospedado sea frágil. Mantener un rastreador confiable frente a la detección en constante evolución de Google significa roturas constantes y un alto costo de mantenimiento. Para casos de uso en producción, los proveedores externos son más confiables y rentables.
Proveedores de Google compatibles actualmente:
Proveedor | Variable de entorno | Notas |
| Pago por uso; generalmente más barato para bajo volumen | |
| 2,500 consultas gratuitas, luego pago por uso |
Ambas son opciones de bajo costo. Para uso casual o de bajo volumen, serpbase.dev tiende a ser más barato por consulta. Cualquiera funciona; configure la que prefiera, o ambas como respaldo.
Búsqueda web
Proveedor | nombre | Método | Autenticación |
DuckDuckGo |
| Rastreo HTML (endpoint lite) | No |
Bing |
| Rastreo HTML | No |
Yahoo |
| Rastreo HTML | No |
Brave |
| API de búsqueda oficial | Opcional (nivel gratuito: 2000/mes) |
Ecosia |
| Rastreo HTML | No |
Mojeek |
| Rastreo HTML | No |
Startpage |
| Rastreo HTML (mejor esfuerzo) | No |
Qwant |
| API JSON interna (mejor esfuerzo) | No |
Yandex |
| Rastreo HTML (mejor esfuerzo) | No |
Baidu |
| Rastreo HTML (mejor esfuerzo) | No |
Los proveedores marcados como mejor esfuerzo utilizan endpoints no documentados o objetivos de rastreo con fuertes medidas anti-bot. Pueden dejar de funcionar sin previo aviso.
Conocimiento / referencia
Proveedor | nombre | Método | Autenticación |
Wikipedia |
| API de acción de MediaWiki | No |
Wikidata |
| API de Wikidata (búsqueda de entidades) | No |
Internet Archive |
| API de búsqueda avanzada | No |
Desarrollador
Proveedor | nombre | Método | Autenticación |
GitHub |
| API REST de GitHub | No (el token aumenta el límite de tasa) |
Stack Overflow |
| API de Stack Exchange | No (la clave aumenta el límite) |
Hacker News |
| API de Algolia HN | No |
| API JSON pública | No | |
npm |
| API del registro npm | No |
PyPI |
| Rastreo HTML | No |
crates.io |
| API REST de crates.io | No |
Académico
Proveedor | nombre | Método | Autenticación |
arXiv |
| API Atom | No |
PubMed |
| E-utilities de NCBI | No (la clave aumenta el límite de tasa) |
Semantic Scholar |
| API de grafo | No (la clave aumenta el límite de tasa) |
CrossRef |
| API REST (más de 145M de DOI) | No |
Instalación
# Clone the repository
git clone https://github.com/your-org/serpent
cd serpent
# Install with pip (editable)
pip install -e ".[dev]"
# Or with uv
uv pip install -e ".[dev]"Configuración
Copie .env.example a .env y rellene sus claves:
cp .env.example .env# Required for Google search (at least one)
SERPBASE_API_KEY=your_key_here
SERPER_API_KEY=your_key_here
# Optional — omit to use unauthenticated/public access
BRAVE_API_KEY= # free tier: 2000 req/month
GITHUB_TOKEN= # raises rate limit from 60 to 5000 req/hour
STACKEXCHANGE_API_KEY= # raises limit from 300 to 10,000 req/day
NCBI_API_KEY= # PubMed; raises from 3 to 10 req/sec
SEMANTIC_SCHOLAR_API_KEY= # raises from 1 to 10 req/sec
# Server
HOST=0.0.0.0
PORT=8000
# Restrict which providers are active (comma-separated, empty = all available)
ENABLED_PROVIDERS=
ALLOW_UNSTABLE_PROVIDERS=false
# Timeouts in seconds
DEFAULT_TIMEOUT=10
AGGREGATOR_TIMEOUT=15
MAX_RESULTS_PER_PROVIDER=10Ejecución
Servidor de API HTTP
python -m serpent.main
# or
serpentEl servidor se inicia en http://localhost:8000. Documentación interactiva en /docs.
Servidor MCP
python -m serpent.mcp_server
# or
serpent-mcpEl servidor MCP se comunica a través de stdio. Úselo con cualquier cliente compatible con MCP (Claude Desktop, cline, continue.dev, etc.).
Docker
Construya la imagen:
docker build -t serpent .Ejecute la API HTTP:
docker run --rm -p 8000:8000 --env-file .env serpentO con Docker Compose:
docker compose up --buildEl contenedor inicia la API HTTP en http://localhost:8000.
API HTTP
POST /search
Agrega la búsqueda en todos los proveedores habilitados.
curl -X POST http://localhost:8000/search \
-H "Content-Type: application/json" \
-d '{"query": "rust async runtime"}'Con proveedores y parámetros explícitos:
curl -X POST http://localhost:8000/search \
-H "Content-Type: application/json" \
-d '{
"query": "rust async runtime",
"providers": ["duckduckgo", "wikipedia"],
"params": {"num_results": 5, "language": "en"}
}'Respuesta:
{
"engine": "serpent",
"query": "rust async runtime",
"results": [
{
"title": "Tokio - An asynchronous Rust runtime",
"url": "https://tokio.rs",
"snippet": "Tokio is an event-driven, non-blocking I/O platform...",
"source": "tokio.rs",
"rank": 1,
"provider": "duckduckgo",
"published_date": null,
"extra": {}
}
],
"related_searches": ["tokio vs async-std", "rust futures"],
"suggestions": [],
"answer_box": null,
"timing_ms": 843.2,
"providers": [
{"name": "duckduckgo", "success": true, "result_count": 10, "latency_ms": 840.1, "error": null},
{"name": "wikipedia", "success": true, "result_count": 3, "latency_ms": 320.5, "error": null}
],
"errors": []
}POST /search/google
curl -X POST http://localhost:8000/search/google \
-H "Content-Type: application/json" \
-d '{"query": "site:github.com rust tokio"}'GET /health
curl http://localhost:8000/health
# {"status": "ok"}GET /providers
curl http://localhost:8000/providers{
"available": [
{"name": "google_serpbase", "tags": ["google", "web"]},
{"name": "duckduckgo", "tags": ["web", "privacy"]},
{"name": "wikipedia", "tags": ["web", "academic", "knowledge"]},
{"name": "github", "tags": ["code", "web"]},
{"name": "arxiv", "tags": ["academic", "web"]}
],
"count": 5
}Uso de MCP
Configure su cliente MCP para ejecutar serpent-mcp (o python -m serpent.mcp_server).
Ejemplo de configuración de Claude Desktop (~/.claude/claude_desktop_config.json):
{
"mcpServers": {
"serpent": {
"command": "serpent-mcp",
"env": {
"SERPBASE_API_KEY": "your_key",
"SERPER_API_KEY": "your_key"
}
}
}
}Herramientas MCP disponibles
search_web
Búsqueda web general en todos los proveedores habilitados.
{
"query": "fastapi vs flask performance 2024",
"num_results": 10
}search_google
Búsqueda en Google a través de un proveedor externo configurado.
{
"query": "site:docs.python.org asyncio",
"provider": "google_serpbase"
}search_academic
Búsqueda en arXiv y Wikipedia.
{
"query": "transformer architecture attention mechanism",
"num_results": 8
}search_github
Búsqueda en repositorios de GitHub.
{
"query": "python mcp server implementation",
"num_results": 5
}compare_engines
Ejecute la misma consulta en múltiples proveedores y devuelva los resultados agrupados por motor.
{
"query": "vector database comparison",
"providers": ["duckduckgo", "brave"],
"num_results": 5
}Referencia del esquema de resultados
Cada objeto de resultado tiene estos campos:
Campo | Tipo | Descripción | |
| string | Título del resultado | |
| string | URL del resultado | |
| string | Extracto de texto / descripción | |
| string | Nombre del dominio | |
| int | Posición basada en 1 en la lista final combinada | |
| string | Proveedor que devolvió este resultado | |
| string | null | Fecha ISO (YYYY-MM-DD), si está disponible |
| object | Datos específicos del proveedor (ej. estrellas de GitHub, autores de arXiv) |
Desarrollo
# Install dev dependencies
pip install -e ".[dev]"
# Run tests
pytest
# Run with auto-reload
uvicorn serpent.main:app --reloadHoja de ruta
[ ] Capa de caché (en memoria / Redis) para consultas repetidas
[ ] Re-clasificación de relevancia entre proveedores
[ ] Más proveedores: Bing (API oficial), Kagi, Tavily
[ ] Limitación de tasa por proveedor con retroceso
[ ] Respuestas en streaming (SSE) para agregaciones largas
[ ] Imagen de Docker y configuración de Compose
[ ] Endpoint de monitoreo de salud del proveedor
[ ] Puntuación de resultados y señales de confianza
Licencia
MIT
Available Tools
5 toolscompare_enginesA
Run the same query against multiple providers and return results grouped by provider for side-by-side comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| providers | No | Providers to compare. Empty = all enabled. | |
| num_results | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool runs queries and returns grouped results, but does not cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what happens when providers fail. For a tool that interacts with multiple external services, this is a significant gap.
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, well-structured sentence that efficiently conveys the tool's purpose and outcome without unnecessary words. It is front-loaded and every part earns its place.
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 querying multiple providers, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error scenarios, output format, and how results are structured for comparison. This is inadequate for a tool with external dependencies and multiple parameters.
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 67% (2 out of 3 parameters have descriptions). The description adds value by explaining the purpose of comparing providers and implying the 'providers' parameter's role, but does not detail the 'query' or 'num_results' beyond what the schema provides. With moderate coverage, it compensates somewhat but not fully.
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 the specific action ('Run the same query against multiple providers') and the outcome ('return results grouped by provider for side-by-side comparison'), distinguishing it from sibling tools that search specific platforms. It uses precise verbs and identifies the resource being compared.
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 implies usage for comparative analysis across providers, but does not explicitly state when to use this tool versus the sibling search tools (search_academic, search_github, etc.). It lacks guidance on alternatives or exclusions, leaving the context somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_academicB
Search academic sources (arXiv, Wikipedia). Best for research questions, paper discovery, and factual lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| num_results | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the sources (arXiv, Wikipedia) but doesn't describe important behaviors like rate limits, authentication needs, result format, pagination, or whether this is a read-only operation. The description is insufficient for a tool with no annotation coverage.
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 extremely concise with just two sentences that are front-loaded and waste-free. The first sentence states the core purpose, and the second provides usage context. Every word earns its place with no redundancy.
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 incomplete parameter documentation (50% schema coverage), the description is insufficiently complete. It doesn't explain what the tool returns, how results are structured, or important behavioral constraints. For a search tool with multiple sibling alternatives, more context is needed.
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 50% (only 'query' has a description). The description adds no specific parameter semantics beyond what the schema provides. It doesn't explain what constitutes a good query format, what 'num_results' controls, or any constraints. With moderate schema coverage, the baseline 3 is appropriate as the description doesn't compensate for the coverage gap.
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 the tool's purpose as 'Search academic sources (arXiv, Wikipedia)' with specific resources named. It distinguishes from siblings by focusing on academic sources rather than general web, GitHub, or engine comparison. However, it doesn't explicitly contrast with each sibling tool by name.
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 provides implied usage guidance with 'Best for research questions, paper discovery, and factual lookups,' suggesting appropriate contexts. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the sibling tools (compare_engines, search_github, search_google, search_web).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_githubC
Search GitHub repositories. Returns repo name, description, stars, language, and topics.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| num_results | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what fields are returned (repo name, description, stars, language, topics) but doesn't cover important aspects like rate limits, authentication requirements, pagination behavior, or error conditions for a search API tool.
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 appropriately brief (two sentences) and front-loaded with the core purpose. Every sentence adds value: the first states what the tool does, the second describes the return format.
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 search tool with 2 parameters, no annotations, and no output schema, the description is insufficient. It doesn't cover authentication needs, rate limits, error handling, or how results are sorted/filtered. The return format is mentioned but without schema details.
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 50% (only 'query' has a description). The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain search query syntax, result ordering, or what 'num_results' default of 10 means in practice.
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 the action ('Search GitHub repositories') and the resource ('GitHub repositories'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_google' or 'search_web' beyond mentioning GitHub specifically.
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 provides no guidance on when to use this tool versus the sibling search tools (compare_engines, search_academic, search_google, search_web). It mentions GitHub but doesn't explain why one would choose GitHub search over other search options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_googleA
Search Google via a configured third-party provider (serpbase or serper). Returns structured organic results, answer boxes, and related searches.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| provider | No | Which Google provider to use. Empty = first available. | |
| num_results | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('structured organic results, answer boxes, and related searches') which is valuable behavioral information. However, it doesn't mention rate limits, authentication needs, error conditions, or pagination behavior that would be helpful for a search tool.
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 perfectly concise with two sentences that each earn their place. The first sentence establishes the core functionality and constraints, while the second specifies the return format. No wasted words, front-loaded with essential information.
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 search tool with 3 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the basic purpose and return format, but lacks details about error handling, rate limits, provider differences, or what happens when no results are found. The absence of output schema means the description should ideally explain more about the return structure.
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?
With 67% schema description coverage, the description adds meaningful context beyond the schema. While the schema documents parameters, the description clarifies that providers are 'serpbase or serper' (matching the enum) and that results include 'organic results, answer boxes, and related searches' - giving semantic meaning to the search operation that the schema alone doesn't provide.
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 the specific action ('Search Google'), identifies the resource ('via a configured third-party provider'), and distinguishes from siblings by specifying it's for Google searches only, unlike 'search_academic' or 'search_github'. It provides verb+resource+scope differentiation.
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 implies usage context by specifying it's for Google searches via particular providers, which helps differentiate from sibling tools like 'search_academic'. However, it doesn't explicitly state when to use this versus alternatives or provide exclusion criteria, leaving some ambiguity about provider selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_webB
Search the web using all enabled providers and return aggregated, deduplicated results with a unified schema. Good for general queries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| providers | No | Explicit provider list (optional). Empty = all enabled. | |
| num_results | No | ||
| language | No | en | |
| country | No | us |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'aggregated, deduplicated results' and 'unified schema,' which adds some behavioral context, but fails to disclose critical traits such as rate limits, authentication needs, error handling, or what 'enabled providers' entails. This is a significant gap for a web search tool with no annotation coverage.
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 sentences, front-loaded with the core functionality and followed by a usage hint. Every word earns its place, with no redundancy or waste, making it highly efficient and easy to scan.
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 a web search tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on result format, error cases, provider specifics, and behavioral constraints, making it inadequate for safe and effective use by an AI agent.
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 40%, with only the 'query' parameter having a description. The description adds no specific parameter semantics beyond what the schema provides, such as explaining 'providers' options or 'language'/'country' effects. It compensates minimally, so the baseline 3 is appropriate given the low coverage.
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 the verb ('Search') and resource ('the web'), specifying it uses 'all enabled providers' and returns 'aggregated, deduplicated results with a unified schema.' It distinguishes from siblings by mentioning 'general queries,' but could be more explicit about how it differs from specific providers like search_google or search_academic.
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 implies usage for 'general queries,' which suggests when to use this tool, but does not explicitly state when not to use it or name alternatives. It lacks clear guidance on choosing between this and sibling tools like search_google or search_academic, leaving usage context somewhat vague.
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.
5 tool updates
v0.1.0- First observed
compare_engines - First observed
search_academic - First observed
search_github - First observed
search_google - First observed
search_web
TDQS
Scored across 5 tools
The tools are mostly distinct, with each targeting a specific search domain (academic, GitHub, Google, web) or a comparison function. However, 'search_web' and 'search_google' could be confused, as Google is a web search provider, but the descriptions clarify that 'search_web' aggregates multiple providers while 'search_google' is specific to Google. This minor overlap is mitigated by clear descriptions.
All tool names follow a consistent verb_noun pattern with snake_case, using 'search_' for four tools and 'compare_' for one. The naming is predictable and readable, with no deviations in style or convention, making it easy for agents to understand and use the tool set.
With 5 tools, the set is well-scoped for a search-focused server. Each tool serves a clear purpose (e.g., different search types and a comparison feature), and there are no extraneous tools. The count is appropriate, allowing coverage of key search domains without being overwhelming.
The tool set covers major search domains (academic, GitHub, Google, general web) and includes a useful comparison tool. Minor gaps exist, such as no tools for filtering or refining search results (e.g., by date or language), but agents can work around this with the provided tools. The surface is largely complete for a search-oriented server.
Related MCP Connectors
Your agent needs the open web — searched by more than one engine, and read as clean markdown rather than raw HTML. **What you can ask for** • "Search this question with two providers and tell me where they disagree." • "Scrape these 40 URLs into markdown, in one batch." • "Crawl this documentation site and give me every page." • "Do deep research on this topic and cite the sources." • "Find the academic papers behind this claim." **How to use it** Point any MCP client at https://mcp.aisa.one/search/mcp and sign in with OAuth — there is no key to create or paste. 30 tools across several independent providers: Tavily and Exa search, answers, contents and agent runs; Firecrawl scrape, batch scrape, crawl, map and search; Perplexity Sonar, Sonar Pro, reasoning and deep research; Oxylabs AI search and LLM jobs; OpenAI and Anthropic web search; and scholarly search. **Why this rather than the source** Several independent indexes behind one account, because one engine's blind spot is not visible from inside it. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the page here, then ask the same agent who links to it or how much traffic it gets — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo-serp/mcp for the Google results page itself, https://mcp.aisa.one/seo-serp-other-engines/mcp for Bing, Baidu and Naver.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Search engine for AI agents to find MCP servers, A2A agents, and skills on their own.
Your agent needs live data — a competitor's traffic, who to contact there, what people are saying, what Google and ChatGPT answer about you, a company's filings. Normally that is six vendor accounts, six sets of keys and six SDKs. This is one URL. **What you can ask for** • "How much traffic does stripe.com get, where does it come from, and who competes for the same keywords?" • "Find 20 Series-B fintech companies in Germany and the heads of marketing there, with emails." • "Does ChatGPT mention our brand when someone asks for the best CRM — and what does it cite?" • "What is X saying about $NVDA today, and what did the stock actually do?" • "Search the web for this, then scrape the three best pages into markdown." **How to use it** Point any MCP client at https://mcp.aisa.one/mcp and sign in with OAuth — there is no key to create or paste. Then just ask: the agent calls search to find the right operation and use to run it. **Why this rather than the source** 26 sources behind one account and one bill — DataForSEO, Semrush, Ahrefs, Similarweb, Apollo, X/Twitter, Instagram, Reddit, Pinterest, YouTube, Tavily, Exa, Perplexity, Firecrawl, CoinGecko, Kalshi, Polymarket, AgentMail and more, 580+ operations. tools/list returns five tools, not 580, so the introduction does not eat your context window. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** One slice at a time: https://mcp.aisa.one/seo/mcp · /finance/mcp · /social/mcp · /search/mcp · /sales/mcp · /mail/mcp · /gtm/mcp, or a single provider like /twitter-api/mcp. Same account, fewer tools listed, and search still reaches everything. Full list at https://mcp.aisa.one/servers
