# wigolo: a local-first MCP server that gives your coding agent search, fetch and crawl without API keys > wigolo bundles a metasearch engine, a headless browser and on-device models behind one MCP surface, so an agent can search, fetch and crawl the web with no cloud account. The keyless core is real; the research and agent tools want an LLM provider, and the licence file does not name a licence. **KnockOutEZ/wigolo** — The go-to web for your AI coding agent — local-first search, fetch, crawl & research over MCP. No API keys, no cloud, $0/query. Public beta. - Repository: https://github.com/KnockOutEZ/wigolo - Website: https://knockoutez.github.io/wigolo/ - Stars: 5,433 · Forks: 446 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/knockoutez-wigolo ## The gap wigolo fills between an agent and the open web A coding agent that cannot reach the web is stuck with whatever is in its context window. The usual fix is a hosted search API: you create an account, get a key, wire it into the agent's config, and pay per query. Every page the agent reads is a request against a rate limit and a line on a bill, which makes agents behave conservatively. They search less than they should because searching costs money. wigolo takes the opposite position. The README describes it as "Local-first web intelligence for AI agents" with "no keys, no cloud, no metered bill", and states that nothing it touches leaves ~/.wigolo/. The target user is anyone running an agent locally, whether that is Claude Code, Cursor, Codex, Gemini CLI, OpenCode, VS Code, Windsurf, Zed or Antigravity, and also people running self-hosted agents through LangChain, CrewAI, LlamaIndex, the Vercel AI SDK or n8n. The project is in public beta and the last push to main was on 2026-09-10, so it is being changed, not frozen. The scope is broader than search. The README lists search, fetch, crawl, extract, cache, find-similar, research and autonomous gather loops as one surface. That matters because the hard part of agentic browsing is not the query, it is the plumbing: rendering JavaScript pages, extracting the readable text, keeping byte offsets so a citation points at the right span, and caching so the agent does not refetch the same URL five times in one session. ## How the MCP server, browser engine and on-device models fit together wigolo is a TypeScript package that publishes a bin entry called wigolo, so the MCP client spawns it as a stdio server. The repository layout shows the shape: src/ holds the server, packages/ and sdks/ hold the embeddable pieces, packaging/ holds the single-file binary build, and benchmarks/ holds separate runners for extraction, search, agent and embedding. There is a Dockerfile with two targets, a Makefile for releases, and an mcp.json plus a smithery.yaml for MCP registries. The local engine is the interesting part. According to the README, init downloads a browser engine and on-device models, and the Dockerfile explains why the OS libraries are baked in at build time: the browser engine's shared libraries are installed as root during the image build, because a first-use lazy install as the non-root node user cannot add system libraries and the browser launch smoke test would fail. That is a real constraint, not a packaging detail. On a normal machine the equivalent step happens during init, which is why init needs roughly 1.5 GB of free disk. Search results come back as structured evidence rather than plain text. The README shows a result carrying an excerpt, a citation_id such as src-1, a source_span with start and end byte offsets described as "byte-exact provenance", and an evidence_score object with final, semantic, lexical and engine_consensus fields. The engine_consensus field implies the metasearch layer queries more than one backend and scores agreement between them. A freshness_signal with a published date is also present. For an agent that has to justify a claim, spans and citation IDs are more useful than a snippet, because the agent can quote a range instead of paraphrasing. The LLM layer is separate and optional. Search, fetch, crawl, extract, cache and find-similar are keyless. research, agent and search format=answer use an LLM to write a synthesized, cited answer, and without one they return a raw brief plus evidence for the agent to assemble. You can point that at gemini, anthropic, openai or groq, or keep it local with WIGOLO_LLM_PROVIDER=ollama or any OpenAI-compatible URL. ## Installing wigolo and running a first search The README's quickstart is two commands. Node 20 or newer is required, on macOS, Linux or Windows, with about 1.5 GB free. The first command sets up the local engine: it downloads the browser engine and on-device models, runs a health check and reports each component. ```bash npx wigolo init ``` If you want an agent wired in the same run, pass a comma-separated list. The README gives claude-code, cursor, codex, gemini-cli, opencode, vscode, windsurf, zed and antigravity as the supported names, and says wigolo writes the MCP config and, where supported, instructions for each. ```bash npx wigolo init --agents=claude-code,cursor ``` Two flags are worth knowing before you run it. --no-warmup defers the downloads until first use, which is useful on a slow connection. The README also states that a failed component download never fails setup: init reports what is not ready with the exact fix and still completes. Read that report rather than assuming a clean exit means a working engine. ```bash npx wigolo doctor ``` doctor is the health check to run after init and any time something behaves oddly. For any MCP client that is not on the supported list, the README says to register npx -y wigolo in that client's own MCP config; the installation guide in docs/ has the exact block per client, plus Docker, Homebrew and single-file-binary channels. There is also an uninstall path that removes everything cleanly: ```bash npx wigolo config --uninstall --yes ``` If you want the synthesized answer rather than a raw brief, set a provider before your agent calls research. The README gives this example for a free Gemini key: ```bash export WIGOLO_LLM_PROVIDER=gemini export GEMINI_API_KEY= ``` Set those in your shell or in the agent's MCP env block. The README points at aistudio.google.com/apikey for the key and says the free tier is plenty. ## Where wigolo stops being the right tool The first limitation is the one the README states plainly: the synthesized-answer tools need an LLM. If you install wigolo and immediately ask your agent to research a topic, you get a raw brief and evidence, not a written answer with citations. That is a deliberate split, and the keyless half is genuinely useful, but anyone expecting a drop-in replacement for a hosted answer API will be surprised. The fix is one environment variable, and it moves you back toward a cloud provider, which is the thing local-first was supposed to avoid. Ollama keeps it local, at the cost of running a model yourself. The second limitation is disk and download weight. Roughly 1.5 GB and a browser engine download is not a trivial install, and on ephemeral CI runners it is a per-run cost. The Dockerfile's full target exists precisely for that case, preinstalling the browser binary because the slim target downloads it on first use into a /data volume. If you run containers with --rm and no persistent volume, the slim target will re-download on every run. The third is maturity. The project calls itself a public beta, releases carry a -beta.N suffix, and the Makefile notes that releases are pre-releases during the beta. The release history shows v0.2.0 and v0.2.1 in July 2026 and a binary build in September 2026. A beta with a moving tool surface is fine for a personal agent and less fine for a pipeline you cannot babysit. Finally, the licence is a real question. The repository's LICENSE file exists, but the metadata reports NOASSERTION, which means the licence could not be identified automatically. The README badge says AGPL-3.0. Those two signals do not agree, and AGPL-3.0 has obligations that matter if you embed the SDK in a network service. Read the LICENSE file yourself before you build on it. ## wigolo against Tavily or Brave Search MCP servers The obvious alternative is a hosted search MCP server, of which Tavily and the Brave Search MCP server are the common picks. The difference is where the work happens. A hosted server sends your query to a vendor, which returns ranked results and, in Tavily's case, an extracted answer. You get a clean answer with no local install, and you pay per query or hit a free-tier ceiling. wigolo runs the metasearch, the page rendering, the extraction and the embedding on your machine, which is why the install is 1.5 GB and the marginal query cost is zero. That trade-off cuts both ways. A hosted vendor maintains its index and its ranking quality; wigolo's engine_consensus score suggests it is aggregating several backends and reconciling them, which is a different bet. It also means wigolo's result quality depends on the backends it queries and on the on-device models, neither of which the README documents in detail. The repository has benchmarks/search and benchmarks/embedding runners, so there is a way to measure this yourself, but the README does not publish numbers you can rely on. A second alternative is a general scraping stack such as Playwright plus a readability extractor, wired into your agent by hand. That gives you full control and no MCP layer. You would then own the caching, the citation spans, the freshness signals and the multi-backend search, which is most of what wigolo is. The honest comparison is that wigolo is a bundle: if you only need to fetch one page occasionally, a Playwright script is smaller than a 1.5 GB engine. ## Maintenance, releases and licence cost The last push to main was on 2026-09-10, and the most recent release listed is binary-v0.2.1-sd507.1 on 2026-09-08, with v0.2.1 before it on 2026-07-19 and v0.2.0 on 2026-07-17. The README says new features and updates ship steadily and points at an X account for release news. That is a normal cadence for a beta, and it also means you should expect the tool surface to move. Upgrading has a specific shape. The Makefile documents that main is protected and requires pull requests, so a release is two steps: make release-beta opens a version-bump PR, and after it merges, make release-tag pushes a tag that triggers the publish workflow. During the beta, versions carry a -beta.N suffix and the GitHub Release is flagged --prerelease, but npm still publishes to the latest dist-tag, so npm install wigolo resolves to a beta build. If you pin versions, pin the exact beta rather than the dist-tag. The upgrade cost you will actually pay is the engine. A new version can change the browser engine or the on-device models, and those are the 1.5 GB. On a workstation that is a background download. On a fleet of agents it is a rollout you have to schedule, and the Dockerfile's two targets are the lever: bake the browser binary into the image for ephemeral runs, or accept a first-use download into a persistent volume. On licence, the repository ships a LICENSE file and a TRADEMARK.md, and the README badge claims AGPL-3.0 while the metadata says NOASSERTION. That discrepancy is not something the README resolves, and the badge alone is not authoritative. If you plan to embed the SDK from sdks/ inside a service other people use, have someone read the actual LICENSE text. That is a factual gap in the repository's own presentation, not a legal opinion. ## Conclusion Adopt wigolo if your agent needs web search and page fetching and you would rather not hand a metered search API a key or a per-query bill; the keyless path covers search, fetch, crawl, extract, cache and find-similar. Do not adopt it if you need a finished synthesized answer out of the box, since research, agent and search format=answer hand back a raw brief and evidence until you configure an LLM provider, and do not adopt it if a NOASSERTION licence file is a blocker for your legal review. Before rolling it out, run npx wigolo init on the target machine and read the per-component report, because a failed browser-engine or model download still lets init complete and only shows up on first use. ## FAQ ### What is wigolo and what does it do for an AI agent? wigolo is a local-first MCP server that gives an AI agent one surface for web tasks: search, fetch, crawl, extract, cache, find-similar, research and autonomous gather loops. It runs next to your agent as an MCP server, as a REST or MCP endpoint on a self-hosted box, or embedded through an SDK. ### Does wigolo need API keys? Search, fetch, crawl, extract, cache and find-similar work with no API key, and the README states nothing it touches leaves ~/.wigolo/. The research, agent and search format=answer tools use an LLM to write a synthesized answer, and without a provider they return a raw brief and evidence instead. ### How do I install wigolo? Run npx wigolo init, which needs Node 20 or newer and about 1.5 GB of free disk on macOS, Linux or Windows. Adding --agents=claude-code,cursor wires the named agents in the same run, and npx wigolo doctor checks health afterwards. ### Which agents and frameworks does wigolo support? The README lists Claude Code, Cursor, Codex, Gemini CLI, OpenCode, VS Code, Windsurf, Zed and Antigravity as names you can pass to --agents, plus LangChain, CrewAI, LlamaIndex, the Vercel AI SDK, n8n and any MCP client or plain REST caller. For anything not on the list, register npx -y wigolo in that client's own MCP config. ## Sources - [Issues](https://github.com/KnockOutEZ/wigolo/issues) - [KnockOutEZ/wigolo on GitHub](https://github.com/KnockOutEZ/wigolo) - [Project website](https://knockoutez.github.io/wigolo/) - [README](https://github.com/KnockOutEZ/wigolo/blob/main/README.md) - [Releases](https://github.com/KnockOutEZ/wigolo/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/knockoutez-wigolo