By peter_lzh Wigolo: A Local-First Web Tooling Layer That Lets AI Agents Search 18 Engines at Once
When you use an AI agent, have you ever noticed this problem: a web page the agent already searched and read gets queried again, and the agent often starts the search from scratch. That is clearly unnecessary. The root cause is that most web tools treat the result as a one-shot answer. Links come back, the summary is consumed, and the next task pays the search, fetch, and read cost all over again.
Wigolo puts search, fetch, content extraction, and local indexing into a single process, so the pages an agent has already looked at serve not only the immediate question but also become the starting point for the next search.
Project Overview
Wigolo is a local-first web tooling layer built for AI agents. It plugs into large-model agents through MCP, and can also be called from the command line, a REST API, or TypeScript/Python SDKs.
When an agent issues a query, Wigolo runs multiple search adapters in parallel, then performs URL normalization, cross-engine deduplication, rank fusion, and on-device model reranking. What it returns is not just titles and URLs, but also original excerpts, citation numbers, source positions, and scoring signals.
Key Features
Wigolo is not a free clone of a paid tool. It is a focused web layer purpose-built for your agents, exposing MCP and REST surfaces they can call directly, with the search and extraction quality that paid services charge for. What makes it different:
- Built for agents. A single MCP call fans out parallel queries across multiple engines, something a serial host-tool loop cannot replicate. Every result is transparently scored per item, and the output is budget-aware.
- Honest output. Stale caches, failed fetches, degraded backends, and truncation are all surfaced explicitly in the results. When a bot-protected page cannot be read, you get a failure labeled blocked_by_challenge instead of the challenge shell being returned as content.
- $0 per query, free re-queries. The default search talks to public engines through direct adapters; the reranker and embeddings run on-device. Every response is cached, so asking again is instant and zero-cost.
- Private by default. Cache, embeddings, models, and configuration all live under
~/.wigolo/. Nothing reaches a third party unless you explicitly opt into LLM synthesis.
Below is an anatomy of a real result. It includes failed engines and weak results, because those are part of the answer too.
Ten Tools, One Continuous Action
Wigolo exposes ten tools to the outside, as shown below:
search finds candidate sources, fetch reads a single page, crawl expands along a site, and extract turns tables, metadata, or a specified schema into structured results. Once content is local, cache, find_similar, diff, and watch handle reuse and tracking.
The remaining research and agent tools chain the earlier actions together: they break down the question, expand queries, fetch sources, then output a citation-backed research result or structured material. When they need a full answer generated, they can connect to major models or local Ollama; even without an LLM configured, they can hand the evidence to the host agent to organize.
Quick Start
The most direct way to use Wigolo today is npm, requiring Node.js 20 or later. To connect it to Codex, just run the init command. After initialization, you can skip the agent and observe a search result directly in the terminal. What is worth watching is not whether it returns three links, but whether the result carries clear excerpts, sources, scores, and failure states. Running the same question again lets you feel directly whether the local cache fits your working rhythm.
The first full preparation downloads a browser engine and local models; the official recommendation is to reserve about 1.5 GB of space. Note that “local-first” does not mean fully offline: search still reaches public engines and fetch still connects to target sites; sites that depend on IP reputation or strict verification may also be unreadable.
