Skip to main content
Glama
lhswgzy

free-search-mcp-ts

by lhswgzy

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
EXA_API_KEYNoOptional API key for the exa engine.
SEARXNG_URLNoPoint the searxng engine at your own instance. Accepts a comma-separated list and fails over between them.
BRAVE_API_KEYNoOptional API key for the brave-api engine.
SERPER_API_KEYNoOptional API key for the serper engine.
TAVILY_API_KEYNoOptional API key for the tavily engine.
FREE_SEARCH_CACHENoSet to `0` to disable the local SQLite index.1
FREE_SEARCH_PROXYNoHTTP(S) proxy, e.g. `http://127.0.0.1:7890`. Standard `HTTPS_PROXY` is also honoured.
FREE_SEARCH_REGIONNoRegion hint, e.g. `us` or `cn`.
FREE_SEARCH_ENGINESNoComma-separated engine ids, or `auto` for the tiered policy.auto
FREE_SEARCH_TIMEOUTNoPer-request timeout in milliseconds.15000
FREE_SEARCH_DATA_DIRNoWhere the index and configuration live.~/.free-search-mcp
FREE_SEARCH_LANGUAGENoLanguage hint, e.g. `en` or `zh`.
FREE_SEARCH_LOG_LEVELNo`silent`, `error`, `warn`, `info` or `debug`.warn
FREE_SEARCH_MAX_RESULTSNoDefault result count.12
FREE_SEARCH_ALLOW_PRIVATENoSet to `1` to allow loopback/private addresses (off by default as an SSRF guard).0
FREE_SEARCH_RESPECT_ROBOTSNoSet to `0` to ignore robots.txt when fetching.1
FREE_SEARCH_CACHE_TTL_HOURSNoHow long a fetched page stays fresh.24

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
web_searchA

Search the web across several independent engines at once and get back one de-duplicated, re-ranked result list. Results from every engine are merged with Reciprocal Rank Fusion, so a page several engines agree on outranks a page only one engine found — this is materially more stable than querying a single provider. Runs with no API key by default; engines that are blocked or failing are skipped automatically and reported. Prefer this over fetch_url when you do not yet know which page has the answer. Use research() when you want the pages read for you as well.

researchA

One call that does the whole mechanical research loop: search several engines, derive extra queries from the vocabulary of the results, fetch the most relevant and diverse sources, then extract the passages from each that actually answer the question. Returns a Markdown brief with numbered, citable sources and verbatim quoted passages — it does NOT paraphrase, because this server has no language model; you write the synthesis from the evidence it gathers. Use this instead of chaining web_search and several fetch_url calls whenever you need more than a snippet. depth 1 = the query as written. depth 2 (default) = the query plus expansions derived from what the first page of results is actually about. depth 3 = broader expansion and more sources.

fetch_urlA

Fetch one web page or document and return its main content as clean Markdown, with the navigation, adverts and cookie banners removed. Handles HTML (via a readability pass), PDF, DOCX, XLSX, PPTX, EPUB, ODT, CSV, JSON and plain text. Results are stored in a local SQLite index, so reading the same URL again is instant and the page becomes searchable offline with search_index. Long pages are truncated rather than refused: the response reports a next offset you can pass back to continue. robots.txt is honoured by default and private/loopback addresses are refused as a safety measure.

fetch_urlsA

Fetch up to 12 URLs concurrently and return each as Markdown under its own heading. Cheaper and faster than calling fetch_url repeatedly because the requests overlap. Failures are reported per URL instead of failing the whole call.

parse_documentA

Read a document from a local path or a URL and return its text as Markdown. Supports PDF, DOCX, XLSX, PPTX, EPUB, ODT, CSV, JSON, HTML and plain text. Spreadsheets become Markdown tables, presentations become one section per slide, DOCX keeps headings, lists and tables, and PDFs get their hyphenation and column artefacts repaired. Everything is parsed on this machine — no upload, no conversion service.

search_indexA

Full-text search over every page this server has already fetched on this machine, using a local SQLite FTS5 index (with CJK bigram support). Use it to recall something you read earlier in the session, to avoid re-fetching, or to work offline. Returns cached page URLs, titles and highlighted snippets — and it costs no network requests at all.

local_indexA

Report on, prune, clear or compact the local cache that stores fetched pages and recent engine responses. stats is safe and cheap; clear and prune delete data permanently.

list_enginesA

Show every engine this server knows about: what it indexes, whether it needs an API key, which tier it belongs to, and its current health (a repeatedly blocked engine is benched for a while). Use it to pick explicit engines for web_search, or to diagnose an empty result list.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 8 tools

Disambiguation4/5

Most tools have clearly distinct roles, and descriptions explicitly route between them (web_search vs research, fetch_url vs fetch_urls). The main overlap is fetch_url and parse_document, which both convert remote documents/HTML to Markdown from a URL, leaving some ambiguity about which to pick for a remote document.

Naming Consistency4/5

The dominant pattern is snake_case verb_noun (fetch_url, fetch_urls, parse_document, search_index, list_engines), which is predictable. Deviations are research (a bare verb/noun) and local_index (a noun phrase rather than an action), but these are minor.

Tool Count5/5

Eight tools is well-scoped for a search/fetch/research server, with each tool earning its place across search, fetch, parse, index recall and engine introspection. No redundancy or padding.

Completeness5/5

The surface covers the full lifecycle: multi-engine search, orchestrated deep research, single and batch fetching, document parsing, offline index recall, cache management and engine introspection. No obvious gaps or dead ends for the stated domain.

Maintenance

ActivityMaintained
ResponsivenessNo issues