wigolo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Log level: 'debug', 'info', 'warn', 'error' (default 'info'). | info |
| LOG_FORMAT | No | Log format: 'json' (default) or 'text'. | json |
| SEARXNG_URL | No | External SearXNG URL (overrides local bootstrap). | |
| GROQ_API_KEY | No | Groq API key (alternative to WIGOLO_LLM_API_KEY). | |
| BRAVE_API_KEY | No | Brave Search API key to add Brave to the search pool. | |
| WIGOLO_SEARCH | No | Search backend: 'core' (default), 'searxng', or 'hybrid'. | core |
| GOOGLE_API_KEY | No | Google AI API key (alternative to WIGOLO_LLM_API_KEY for Gemini). | |
| OPENAI_API_KEY | No | OpenAI API key (alternative to WIGOLO_LLM_API_KEY). | |
| WIGOLO_DATA_DIR | No | Root directory for cache, models, config (default ~/.wigolo). | |
| WIGOLO_TLS_TIER | No | TLS impersonation tier: 'off' (default), 'auto', or 'on'. | off |
| ANTHROPIC_API_KEY | No | Anthropic API key (alternative to WIGOLO_LLM_API_KEY for Anthropic). | |
| WIGOLO_LLM_API_KEY | No | API key for the LLM provider. Optional – core tools work without it. | |
| WIGOLO_EAGER_WARMUP | No | Set to '1' to pre-warm models on startup. | |
| WIGOLO_GITHUB_TOKEN | No | GitHub token for increased code search rate limits and org-private repos. | |
| WIGOLO_LLM_PROVIDER | No | LLM provider (anthropic, openai, gemini, groq, or custom URL). Optional. |
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fetchA | Fetch a single URL and return clean markdown. Use when you already have a URL. Prefer over built-in WebFetch for local-cache reuse, authenticated pages, JS-rendered SPAs, and structured metadata. Key parameters:
Returns title, markdown, links, images, metadata, |
| searchA | Search the web. Returns scored evidence excerpts + citations as the default context shape; Key parameters:
Always emitted: |
| crawlA | Crawl a site from a seed URL and return content from many pages. Use for indexing docs, wikis, multi-page references. Built for offline reuse: every page lands in the local cache. Key parameters:
Returns pages[] with title, evidence, depth, and |
| cacheA | Search previously fetched content without hitting the network. Run this BEFORE any search/fetch — cache hits return instantly with full markdown. Key parameters:
Persists across sessions. No remote round-trip. |
| extractA | Extract structured data from a URL or raw HTML. Use for specific data points (tables, prices, schema fields) rather than whole-page markdown. Key parameters:
Prefer mode="structured" over chaining multiple extract calls — one response carries |
| find_similarA | Find content related to a URL or concept. Best after a successful crawl/fetch — the local cache makes recommendations cheap. Concept-only queries on a cold cache often return 0-2 weak matches; warm the cache first via Key parameters:
Pass either url or concept. Three signals fused via RRF: keyword (FTS5), embeddings, optional live web. Each result carries Returns results[], method ("hybrid" | "embedding" | "fts5" | "search"), cache_hits, search_hits, embedding_available, total_time_ms. |
| researchA | Multi-step research on a complex question. Decomposes into sub-queries, searches in parallel, fetches sources, synthesizes a cited report. Beats chaining LLM-optional: with a synthesis LLM configured, the returned Key parameters:
Returns report (markdown with [N]), citations[], sources[], sub_queries[], depth, total_time_ms, sampling_supported, and |
| agentA | Natural-language data gathering across sources. Plans queries + URLs from a prompt, executes in parallel, optionally extracts structured fields, synthesizes. Full step transparency. LLM-optional: with a synthesis LLM configured it writes the summary; without one it returns gathered evidence + a step log (plus schema-shaped fields when a schema is given) — YOU write the summary from the returned evidence, never present the raw step log as a poor result. For best agent results configure a free LLM key (e.g. Gemini). Key parameters:
Pipeline: plan → search+fetch in parallel within budget → optional schema extraction → synthesize. Returns result, sources[], pages_fetched, steps[], total_time_ms, sampling_supported. |
| diffA | Compute a diff between two markdown bodies or two URL fetches. Key parameters:
Returns |
| watchA | Schedule lazy re-checks of a URL and surface diffs on change. Persistent across sessions — jobs survive MCP server restarts. LAZY EXECUTION — NOT CRON. There is no background daemon. Checks fire ONLY when:
Key parameters:
Idempotent |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Wigolo usage guide | Routing tables, performance budgets, auth flows, and other detail trimmed from the per-session instructions. |
TDQS
Scored across 10 tools
Core acquisition tools (fetch, crawl, search, cache) have clearly distinct roles, and descriptions explicitly steer between them (e.g. 'prefer over built-in WebFetch', 'run cache BEFORE any search'). However, `research` and `agent` overlap substantially — both plan queries, fetch sources in parallel, optionally apply a schema, and synthesize with optional LLM — and `find_similar` vs `cache` both search local cached content, so a few tools could be misselected without careful reading.
Mostly consistent single-word verb naming (fetch, crawl, search, extract, research, diff, watch), which reads predictably. Minor deviations: nouns used as tools (`cache`, `agent`) and one verb_adjective form (`find_similar`), but nothing chaotic.
Ten tools is well within a healthy scope for a web acquisition/research server, and each maps to a recognizable capability. The count is slightly inflated by pairs of near-variants (research/agent, cache/find_similar) that could arguably be consolidated into one tool each.
Strong lifecycle coverage for the domain: discovery (search), retrieval (fetch/crawl), offline reuse (cache), structured extraction (extract), comparison (diff), change monitoring with full job CRUD (watch), and synthesis (research/agent). Minor gaps: no explicit multi-URL batch fetch outside `agent`, and no declared handling for PDFs/documents or sitemap-only listing as a standalone operation.