wigolo: a local MCP web layer for coding agents, keyless by default
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.
At a glance
- What is it?
- wigolo is a TypeScript MCP server that gives an AI agent search, fetch, crawl, extract, cache, find-similar and research tools while keeping traffic and cache under ~/.wigolo/. The keyless tier is real; the synthesized-answer tier is not, and the licence file needs reading before you ship it.
- Who is it for?
- Adopt wigolo if your agent needs web evidence and you want the fetch, crawl and extract path to stay on your machine with no metered key. Do not adopt it if you need a finished cited answer out of the box and will not configure an LLM provider, or if AGPL-3.0 terms are incompatible with how you distribute your product.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap wigolo fills between an agent and the open web
A coding agent that needs a current fact has three bad options. It can call a hosted search API, which means an account, a key, and a bill that scales with how much the agent thinks. It can be handed a URL and asked to fetch it, which usually means the agent improvises with curl and gets HTML it cannot cite. Or it can be given a retrieval corpus that someone else assembled, which is stale the moment it is built. wigolo targets the first and third of those. The README describes it as giving an agent "one surface for everything web-related: search, fetch, crawl, extract, cache, find-similar, research, and autonomous gather loops." The intended user is someone running Claude Code, Cursor, Codex, Gemini CLI, OpenCode, VS Code, Windsurf, Zed or Antigravity locally, or running a self-hosted agent framework such as LangChain, CrewAI, LlamaIndex, the Vercel AI SDK or n8n. The claim that matters is the storage boundary: nothing it touches leaves ~/.wigolo/.
How the MCP tool surface and the evidence payload fit together
wigolo runs as an MCP server, so the agent sees tools rather than a search box. The README lists search, fetch, crawl, extract, cache, find-similar and research as distinct tools, and the installation guide gives a config block per client. The output shape is the part worth studying. Each result carries a verbatim excerpt, a citation_id such as src-1, a source_span with byte offsets (the README example shows start 1042 and end 1305), and an evidence_score object with final, semantic, lexical and engine_consensus fields. A separate citations array maps ids back to URLs, and a freshness_signal carries a published date. That structure is what separates this from handing an agent raw HTML: the agent can quote a span and point at where in the document it came from. The engine_consensus field implies results are merged across more than one upstream search engine, which matches the metasearch topic on the repository. The README does not document the merge or ranking algorithm, so how consensus is computed is not something you can verify from the supplied material.
What the keyless tier actually covers, and where the LLM boundary sits
This is the distinction most likely to cause a surprise. Search, fetch, crawl, extract, cache and find-similar are described as fully keyless. The research tool, the agent tool, and search with format=answer are not: they use an LLM to write the synthesized, cited answer. Without a provider configured, the README states they hand back a raw brief and evidence for your agent to assemble. So the phrase no API keys is accurate for the retrieval layer and conditional for the synthesis layer. A free Gemini key is the documented path to a finished answer, set through WIGOLO_LLM_PROVIDER=gemini and GEMINI_API_KEY. Anthropic, OpenAI and Groq are named as alternatives, and WIGOLO_LLM_PROVIDER=ollama keeps the whole loop local. The README also mentions a keyless local-model ladder in the configuration guide, which suggests a fallback chain, but the ladder itself is not reproduced in the supplied material.
Installing it: the two commands and the disk cost
Setup is a single npx invocation. `npx wigolo init` sets up the local engine on any system; `npx wigolo init --agents=claude-code,cursor` also writes the MCP config for the named agents in the same run. The --agents flag accepts a comma-separated list from claude-code, cursor, codex, gemini-cli, opencode, vscode, windsurf, zed and antigravity. Any other MCP client registers `npx -y wigolo` in its own config instead. Requirements are Node 20 or later and roughly 1.5 GB of free disk on macOS, Linux or Windows, because init downloads a browser engine and on-device models. Two flags change the shape of that download: --no-warmup defers it until first use, and --interactive or --wizard swap the unattended flow for a prompt or a TUI. The README states that a failed component download never fails setup, and that init reports what is not ready with the exact fix. `npx wigolo doctor` re-checks health at any time, and `npx wigolo config --uninstall --yes` removes everything.
The 1.5 GB download and the beta label are the real adoption costs
The disk requirement is not incidental. Downloading a browser engine and on-device models means init is a multi-minute, network-heavy operation, and it is the step most likely to fail behind a corporate proxy or on a locked-down CI runner. The --no-warmup flag exists precisely because that cost is unwelcome in some environments, but deferring it moves the failure to the agent's first tool call instead of setup. The second constraint is the status: the repository labels itself a public beta. The README says new features ship steadily and points at a personal X account for updates, which tells you the release cadence is real but the interface is not frozen. The third is the licence. The GitHub metadata reports NOASSERTION while the README badge says AGPL-3.0. Those disagree, and the supplied material does not resolve which governs. Treat the licence as unverified until you read the actual licence file.
Where a hosted search API is still the better answer
The obvious alternative is a hosted search API such as Brave Search or Tavily, wired into the agent as a tool. The difference is not quality, it is where the work happens and who pays. A hosted API returns ranked results from one engine, already deduplicated and maintained by the vendor, with an SLA and a per-query price. wigolo instead runs the retrieval locally, merges engines, and keeps a cache under ~/.wigolo/, which is why the marginal cost per query is zero and why nothing leaves the machine. The trade is operational: you own the 1.5 GB, the model downloads, the browser engine, and the upgrade path. If your agents run in ephemeral containers where a persistent home directory is not available, the local-first model works against you, and a hosted endpoint is the simpler fit. If your queries are few and your tolerance for per-query billing is high, the same conclusion holds.
Maintenance, release cadence and what NOASSERTION means for you
The release history shows v0.2.0 and v0.2.1 in July 2026, then a binary-v0.2.1-sd507.1 build in September 2026, and the repository's last push is 2026-09-10. Two version numbers on the same underlying release implies a separate binary distribution channel tracked alongside the npm package, which the README confirms by listing Docker, Homebrew and single-file-binary options. Practically, that means upgrades arrive as npm version bumps plus periodic binary rebuilds, and the uninstall path (`npx wigolo config --uninstall --yes`) is documented, so backing out is cheap. The licence question is the one to settle before adoption. AGPL-3.0 carries network-copyleft obligations that matter if you expose a modified wigolo as a service; a NOASSERTION value in repository metadata usually means the licence file is non-standard or unparsed. That is not legal advice, and the only reliable move is to read the licence file in the repository and confirm it with whoever handles compliance on your side.
Editorial conclusion
Adopt wigolo if your agent needs web evidence and you want the fetch, crawl and extract path to stay on your machine with no metered key. Do not adopt it if you need a finished cited answer out of the box and will not configure an LLM provider, or if AGPL-3.0 terms are incompatible with how you distribute your product. Before wiring anything, run npx wigolo init and read the per-component report, then confirm the actual licence text in the repository rather than the badge.
Community notes