Skip to main content
Glama
sweetcornna

free-search-mcp

by sweetcornna
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

List available search engines

engines
Read-onlyIdempotent

List available search providers for the search and research tools. Use it to discover valid identifiers for the provider parameter, enabling user selection and configuration.

Instructions

List engine names accepted by the engines= parameter of search / research.

Best for:
- Discovering what's installable before passing a non-default engine.
- Building user-facing UIs that let humans pick engines.

Not recommended for:
- Calling on every search — the list is static; cache it.

Returns:
- The live, complete list of engine name strings. The buckets below are
  illustrative; always trust the returned list over this doc.

Common mistakes:
- Passing one of these names as a query to `search` — they go in the
  `engines=` argument, not `query`.
- Passing a key-only engine (brave_api/serper/tavily/google_cse) with no key
  configured — it returns an actionable error, not results.

Defaults: duckduckgo + mojeek + googlenews + bing (reliable, all-HTTP,
          low-latency; googlenews is an RSS index with structured publish
          dates and its URLs resolve to the real publisher on
          fetch/research; bing's www4 edge answers in ~0.3s).
Keyless opt-in: google + serpsearch (Google SERP scrapers, HTTP-first),
          anysearch (JSON aggregator), startpage (browser-rendered, slower),
          brave (PoW captcha after a few calls), baidu
          (CN index), bilibili (CN video), zhihu (CN Q&A, often login-gated),
          sogou + so360 (CN indexes; sogou returns redirect URLs),
          wikipedia (encyclopedia, follows SEARCH_MCP_REGION language),
          openlibrary (books),
          searx (public-instance meta-search; set SEARCH_MCP_SEARX_INSTANCES
          if it returns nothing).
Vertical (auto-selected by `category`, see below): arxiv, openalex,
          crossref, pubmed (papers); github, stackexchange, hackernews
          (code and developer discussion); gdelt (worldwide news).
Key-required (configure via admin UI / SEARCH_MCP_*_API_KEY): brave_api,
          serper, tavily, google_cse, github_code (GitHub rejects anonymous
          code search).

You usually do NOT need to pass `engines=` for these. Passing `category=`
to `search`/`research` routes the query to the sources that natively index
it — `category="paper"` actually queries arXiv/OpenAlex/Crossref instead of
filtering general web results by hostname. Naming engines explicitly turns
that routing off.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Tool Definition Quality

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Building on the readOnly and idempotent annotations, the description adds substantial behavioral detail: the list is live and complete, buckets are illustrative, the tool may return an actionable error for key-only engines with no key, and engine results are static/cacheable. It also discloses operational nuances like HTTP-first behavior and captcha issues, which go far beyond the annotation hints.

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 long but well-structured with clear section labels ('Best for', 'Not recommended for', 'Returns', 'Common mistakes', and engine category groupings). The core purpose is front-loaded, and while the engine-by-engine details are extensive, they are substantive and directly useful for selecting the right engine. A minor deduction for slightly verbose enumeration that could be partly externalized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool, the description is remarkably complete: it explains the return type, provides defaults, keyless opt-ins, verticals, key-required engines, common mistakes, and sibling relationships. The output schema exists, but the description still covers behavior and integration context, making it fully self-sufficient.

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?

The tool has zero parameters, so the input schema is empty and the description needs no parameter explanation. It earns the baseline 4 by clearly explaining the meaning and usage of the returned values (engine name strings) in the context of other tools, even though an output schema exists. It adds value by clarifying how these names are consumed by `search` and `research`.

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 opens with a crisp, specific statement: 'List engine names accepted by the `engines=` parameter of `search` / `research`.' This uses a clear verb+resource and immediately distinguishes this tool from sibling search/fetch tools by focusing on engine name discovery. It answers both what and why.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use ('Best for: Discovering what's installable before passing a non-default engine', 'Building user-facing UIs') and when not (not for calling on every search, cache it). It also details the alternative of using `category=` with `search`/`research` instead of explicit engines, giving clear, actionable guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sweetcornna/free-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server