free-search-mcp-ts
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EXA_API_KEY | No | Optional API key for the exa engine. | |
| SEARXNG_URL | No | Point the searxng engine at your own instance. Accepts a comma-separated list and fails over between them. | |
| BRAVE_API_KEY | No | Optional API key for the brave-api engine. | |
| SERPER_API_KEY | No | Optional API key for the serper engine. | |
| TAVILY_API_KEY | No | Optional API key for the tavily engine. | |
| FREE_SEARCH_CACHE | No | Set to `0` to disable the local SQLite index. | 1 |
| FREE_SEARCH_PROXY | No | HTTP(S) proxy, e.g. `http://127.0.0.1:7890`. Standard `HTTPS_PROXY` is also honoured. | |
| FREE_SEARCH_REGION | No | Region hint, e.g. `us` or `cn`. | |
| FREE_SEARCH_ENGINES | No | Comma-separated engine ids, or `auto` for the tiered policy. | auto |
| FREE_SEARCH_TIMEOUT | No | Per-request timeout in milliseconds. | 15000 |
| FREE_SEARCH_DATA_DIR | No | Where the index and configuration live. | ~/.free-search-mcp |
| FREE_SEARCH_LANGUAGE | No | Language hint, e.g. `en` or `zh`. | |
| FREE_SEARCH_LOG_LEVEL | No | `silent`, `error`, `warn`, `info` or `debug`. | warn |
| FREE_SEARCH_MAX_RESULTS | No | Default result count. | 12 |
| FREE_SEARCH_ALLOW_PRIVATE | No | Set to `1` to allow loopback/private addresses (off by default as an SSRF guard). | 0 |
| FREE_SEARCH_RESPECT_ROBOTS | No | Set to `0` to ignore robots.txt when fetching. | 1 |
| FREE_SEARCH_CACHE_TTL_HOURS | No | How 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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 |
| 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. |
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
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.
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.
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.
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.