Composing MCP intelligence tools — how does wigolo fit in the broader agent toolchain?

[shift-zero]

Hey team! 👋

I just discovered wigolo through GitHub trending, and I'm genuinely impressed by the design. The local-first philosophy, the transparent per-result scoring, and especially the explicit failure labeling ("blocked_by_challenge" instead of silently returning a challenge page) are refreshing in a space full of black-box SaaS products.

What I'm curious about is how you see wigolo composing with other MCP-based tools in an agent's toolchain. Most projects I see in the MCP ecosystem are specialized — one tool for code, one for web, one for databases, etc. wigolo seems to take a broader approach with its 10 tools covering everything from search to crawl to watch/diff.

Is the design philosophy that wigolo should be the complete "web layer" for an agent, with composition handled at the framework level (LangChain, Vercel AI SDK, etc.)? Or do you envision more direct interop between wigolo and other MCP servers?

A concrete example: If I'm debugging a runtime error, I'd want:

1. An MCP code tool to find the relevant code paths and dependency graph
2. wigolo to search for the error message across docs/SO/GitHub issues
3. Both results synthesized together

Does wigolo have any built-in awareness of other tools, or is that entirely up to the agent/host?

Also, I noticed wigolo explicitly calls out the datacenter IP limitation for challenge-protected sites, which is refreshingly honest. I run into this problem myself (my provider's IP range is flagged everywhere) — any tips beyond the proxy guide for people in that boat?

Great work, and congrats on the trending traction! 🚀

[KnockOutEZ]

Thanks, and glad the honest-labeling design landed. That's the intent.

On philosophy: yes, wigolo is meant to be the web-intelligence layer, not a framework. The surface is broad where most MCP servers are narrow because the 10 tools are really one subsystem with 10 entry points. They share a local substrate: search warms the cache, crawl populates it, cache and find_similar read it, diff and watch compare against it, with embeddings and rerank under all of them. That shared state is the thing you can't rebuild by wiring together N single-purpose MCP servers, since each would have its own silo, no shared cache, no cross-tool provenance. So "broad" is one web brain with many doors, not scope creep.

Composition across domains (code, web, db) is deliberately the host's job, which answers your second question: no built-in awareness of other tools, on purpose. wigolo exposes tools plus instructions, returns structured evidence (stable citation ids, source spans, per-result scores), and lets the host (Claude Code, LangChain, Vercel AI SDK, n8n, whatever) own orchestration and synthesis. Putting cross-tool awareness in the server would break the composability MCP gives you for free. Your debugging example is the intended shape exactly: the code tool finds the paths, wigolo owns the web leg (search the error across docs, SO, GitHub issues) and hands back citable evidence, and the agent fuses both. That's why the default response is evidence rather than prose, so the host can line it up against another tool's output. (There's a format: 'answer' mode when you want wigolo to synthesize its own leg, but the evidence shape is the default precisely for multi-tool work.)

Direct MCP-to-MCP interop, servers calling each other sideways, isn't something we do or plan; the host is the composition point, and server-to-server side channels are an anti-pattern in the model. What we do invest in is making wigolo easy to fuse: stable ids, source spans, and research briefs with cross-references and explicit gaps. And if you're composing outside an MCP host, say a plain script or an n8n flow, serve mode exposes the same engine over a REST surface with an OpenAPI spec, so you can drive it without the MCP layer.

On the datacenter-IP problem, the honest version, ranked by what moves the needle. The classifier scores your IP reputation and fingerprint. wigolo can rotate the fingerprint and TLS; it can't launder the IP. So:

1. The IP is the lever, and the kind of proxy matters. A residential, ISP, or mobile proxy on the flagged tier flips most of these, because the site is judging the IP, not you. A datacenter proxy won't help; it's the same class the site already flags. The proxy guide is really "use the right kind."
2. Run wigolo from a residential IP. This is the local-first payoff: if your provider's range is burned, run it from a laptop on home wifi or a small always-on box behind a residential line and you skip datacenter classification entirely. A SaaS scraper can't do that, since it's always on a datacenter IP. You can.
3. Save the opt-in solver/proxy escape-hatch for the sites worth the per-request cost.
4. Branch on the label. blocked_by_challenge is the tool telling you the truth so your agent can route around it (cache hit, alternate source, reworded query) instead of ingesting a challenge page as content. In a toolchain that honest signal usually beats a flaky "success."

What we won't ship is evasion that impersonates a residential user we're not, or a promise of datacenter-IP success we can't keep. The ceiling is real, so we label it.

Field reports like this help. Anti-bot egress is high on the near-term list; it's the most common thing we hear from people running wigolo against protected sites. Appreciate the detailed note, and the trending mention.

[shift-zero]

Really appreciate the thoughtful reply — this clarifies a lot.

The "one web brain with many doors" framing is the clearest explanation of the broad-but-coherent surface I've seen. The shared substrate (cache, embeddings, rerank) is the key insight I was missing when I asked about composition — wiring N single-purpose MCP servers wouldn't give you that shared state, so the breadth is actually the architecture, not scope creep.

The format: "answer" vs default evidence distinction is also really useful to know. Having the evidence shape be the default specifically for multi-tool fusion makes a lot of design sense.

On the datacenter IP problem — the branch-on-label pattern (routing around blocked_by_challenge instead of fighting it) is pragmatic. I appreciate that you're honest about the ceiling rather than promising something you can't deliver. That's rare.

Looking forward to seeing what comes on the anti-bot egress front. Thanks again for the detailed walkthrough!