de en es ja ko ru zh

serpent

Name: serpent
Author: reurinkkeano

by reurinkkeano

Overview Schema Source Related Servers Discussions Admin

Python

Remote

serpent

Ein Open-Source-Metasuch-Backend, das für MCP- / KI-Agenten-Workflows entwickelt wurde.

Es aggregiert Ergebnisse von mehreren Suchmaschinen, gibt ein einheitliches Schema zurück und stellt sowohl eine Standard-HTTP-API als auch einen MCP-Server bereit, den LLM-Agenten direkt aufrufen können.

Warum existiert dies?

Die meisten Suchaggregatoren sind für menschenlesbare Ausgaben konzipiert: HTML-Seiten, Ergebniskarten, Paginierungs-UIs. Wenn ein LLM-Agent das Web durchsuchen muss, benötigt er etwas anderes: strukturiertes JSON, stabile Feldnamen, gleichzeitige Ergebnisse aus mehreren Quellen und eine vorhersehbare Fehlerbehandlung.

serpent ist für diesen Anwendungsfall konzipiert. Es ist kein SearXNG-Klon.

Positionierung

Agentenfreundliches Metasuch-Backend
MCP-First-Such-Gateway für LLM-Workflows
Strukturierte Such-API für KI-Pipelines

Unterstützte Anbieter

Google

Google wird nicht direkt gescrapt. Der Grund ist praktisch: Googles Anti-Bot-Maßnahmen machen selbst gehostetes Scraping anfällig. Die Aufrechterhaltung eines zuverlässigen Scrapers gegen Googles sich ständig weiterentwickelnde Erkennung bedeutet ständige Ausfälle und einen hohen Wartungsaufwand. Für Produktionsanwendungsfälle sind Drittanbieter zuverlässiger und kostengünstiger.

Derzeit unterstützte Google-Anbieter:

Anbieter	Umgebungsvariable	Hinweise
serpbase.dev	`SERPBASE_API_KEY`	Pay-per-Use; generell günstiger bei geringem Volumen
serper.dev	`SERPER_API_KEY`	2.500 kostenlose Abfragen, danach Pay-per-Use

Beide sind kostengünstige Optionen. Für gelegentliche oder geringe Nutzung ist serpbase.dev pro Abfrage tendenziell günstiger. Beide funktionieren; konfigurieren Sie, was Sie bevorzugen, oder beide als Fallback.

Websuche

Anbieter	Name	Methode	Authentifizierung
DuckDuckGo	`duckduckgo`	HTML-Scraping (Lite-Endpunkt)	Nein
Bing	`bing`	HTML-Scraping	Nein
Yahoo	`yahoo`	HTML-Scraping	Nein
Brave	`brave`	Offizielle Such-API	Optional (kostenlose Stufe: 2000/Monat)
Ecosia	`ecosia`	HTML-Scraping	Nein
Mojeek	`mojeek`	HTML-Scraping	Nein
Startpage	`startpage`	HTML-Scraping (Best-Effort)	Nein
Qwant	`qwant`	Interne JSON-API (Best-Effort)	Nein
Yandex	`yandex`	HTML-Scraping (Best-Effort)	Nein
Baidu	`baidu`	HTML-Scraping (Best-Effort)	Nein

Anbieter, die als Best-Effort gekennzeichnet sind, verwenden undokumentierte Endpunkte oder Scraping-Ziele mit starken Anti-Bot-Maßnahmen. Sie können ohne Vorwarnung aufhören zu funktionieren.

Wissen / Referenz

Anbieter	Name	Methode	Authentifizierung
Wikipedia	`wikipedia`	MediaWiki Action API	Nein
Wikidata	`wikidata`	Wikidata API (Entitätssuche)	Nein
Internet Archive	`internet_archive`	Advanced Search API	Nein

Entwickler

Anbieter	Name	Methode	Authentifizierung
GitHub	`github`	GitHub REST API	Nein (Token erhöht Ratenlimit)
Stack Overflow	`stackoverflow`	Stack Exchange API	Nein (Schlüssel erhöht Limit)
Hacker News	`hackernews`	Algolia HN API	Nein
Reddit	`reddit`	Öffentliche JSON-API	Nein
npm	`npm`	npm Registry API	Nein
PyPI	`pypi`	HTML-Scraping	Nein
crates.io	`crates`	crates.io REST API	Nein

Akademisch

Anbieter	Name	Methode	Authentifizierung
arXiv	`arxiv`	Atom API	Nein
PubMed	`pubmed`	NCBI E-utilities	Nein (Schlüssel erhöht Ratenlimit)
Semantic Scholar	`semanticscholar`	Graph API	Nein (Schlüssel erhöht Ratenlimit)
CrossRef	`crossref`	REST API (145M+ DOIs)	Nein

Installation

# 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]"

Konfiguration

Kopieren Sie .env.example nach .env und tragen Sie Ihre Schlüssel ein:

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=10

Ausführung

HTTP-API-Server

python -m serpent.main
# or
serpent

Der Server startet unter http://localhost:8000. Interaktive Dokumentation unter /docs.

MCP-Server

python -m serpent.mcp_server
# or
serpent-mcp

Der MCP-Server kommuniziert über stdio. Verwenden Sie ihn mit jedem MCP-kompatiblen Client (Claude Desktop, cline, continue.dev, etc.).

Docker

Bauen Sie das Image:

docker build -t serpent .

Führen Sie die HTTP-API aus:

docker run --rm -p 8000:8000 --env-file .env serpent

Oder mit Docker Compose:

docker compose up --build

Der Container startet die HTTP-API unter http://localhost:8000.

HTTP-API

POST /search

Aggregiert die Suche über alle aktivierten Anbieter.

curl -X POST http://localhost:8000/search \
  -H "Content-Type: application/json" \
  -d '{"query": "rust async runtime"}'

Mit expliziten Anbietern und Parametern:

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"}
  }'

Antwort:

{
  "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
}

MCP-Nutzung

Konfigurieren Sie Ihren MCP-Client so, dass er serpent-mcp (oder python -m serpent.mcp_server) ausführt.

Beispiel für die Claude Desktop-Konfiguration (~/.claude/claude_desktop_config.json):

{
  "mcpServers": {
    "serpent": {
      "command": "serpent-mcp",
      "env": {
        "SERPBASE_API_KEY": "your_key",
        "SERPER_API_KEY": "your_key"
      }
    }
  }
}

Verfügbare MCP-Tools

`search_web`

Allgemeine Websuche über alle aktivierten Anbieter.

{
  "query": "fastapi vs flask performance 2024",
  "num_results": 10
}

`search_google`

Google-Suche über einen konfigurierten Drittanbieter.

{
  "query": "site:docs.python.org asyncio",
  "provider": "google_serpbase"
}

`search_academic`

Suche in arXiv und Wikipedia.

{
  "query": "transformer architecture attention mechanism",
  "num_results": 8
}

`search_github`

Suche in GitHub-Repositories.

{
  "query": "python mcp server implementation",
  "num_results": 5
}

`compare_engines`

Führen Sie dieselbe Abfrage über mehrere Anbieter aus und geben Sie die nach Engine gruppierten Ergebnisse zurück.

{
  "query": "vector database comparison",
  "providers": ["duckduckgo", "brave"],
  "num_results": 5
}

Referenz des Ergebnisschemas

Jedes Ergebnisobjekt hat diese Felder:

Feld	Typ	Beschreibung
`title`	string	Ergebnistitel
`url`	string	Ergebnis-URL
`snippet`	string	Textauszug / Beschreibung
`source`	string	Domainname
`rank`	int	1-basierte Position in der endgültigen zusammengeführten Liste
`provider`	string	Anbieter, der dieses Ergebnis zurückgegeben hat
`published_date`	string	null	ISO-Datum (JJJJ-MM-TT), falls verfügbar
`extra`	object	Anbieterspezifische Daten (z. B. GitHub-Sterne, arXiv-Autoren)

Entwicklung

# Install dev dependencies
pip install -e ".[dev]"

# Run tests
pytest

# Run with auto-reload
uvicorn serpent.main:app --reload

Roadmap

[ ] Caching-Schicht (In-Memory / Redis) für wiederholte Abfragen
[ ] Relevanz-Neubewertung über Anbieter hinweg
[ ] Weitere Anbieter: Bing (offizielle API), Kagi, Tavily
[ ] Ratenbegrenzung pro Anbieter mit Backoff
[ ] Streaming-Antworten (SSE) für lange Aggregationen
[ ] Docker-Image und Compose-Setup
[ ] Endpunkt zur Überwachung des Anbieterstatus
[ ] Ergebnis-Scoring und Konfidenzsignale

Lizenz

MIT

Available Tools

5 tools

compare_enginesA

Run the same query against multiple providers and return results grouped by provider for side-by-side comparison.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query
`providers`	No	Providers to compare. Empty = all enabled.
`num_results`	No

TDQS

A3.6/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query
`num_results`	No

TDQS

B3.2/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query
`num_results`	No

TDQS

C2.9/5.0

Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query
`provider`	No	Which Google provider to use. Empty = first available.
`num_results`	No

TDQS

A4.1/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema

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

B3.2/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 updatesv0.1.0Apr 13, 2026
- First observedcompare_engines
- First observedsearch_academic
- First observedsearch_github
- First observedsearch_google
- First observedsearch_web

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-04-13 20:05 across 5 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

AIsa Web Search & Research AOAuth
one.aisa
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.
Browser Automation Search Web Scraping
351
qsearch A
io.github.theYahia
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Search RAG Systems
22
mcp-public A
io.github.tiza-ai
Search engine for AI agents to find MCP servers, A2A agents, and skills on their own.
Search Autonomous Agents AI & Machine Learning
21
AIsa AOAuth
one.aisa
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
Finance Search Social Media
51