{
  "markdown": "<!--\nREADME DESIGN:\n\n  Product principle.\n    The README is the product — it answers three questions in under\n    60 seconds: what this does, why you should care, how to use it.\n    Readme-driven development: changes that affect the README's claims\n    SHALL update the README before or alongside the code change. A README\n    that promises something the server does not deliver is a defect.\n    Every numeric claim (tool count, provider count, zero-config count)\n    reconciles against src/index.ts and config.json — the validator\n    enforces this (Surface reconciliation).\n\n  Voice: Professional, confident, benefit-first. Direct address (\"you\").\n    No first-person (\"we\", \"I\", \"our\"). Short declarative fragments in the\n    tagline. Every sentence survives a reader who knows nothing about\n    Infobroker.\n\n  Demo: Natural-language prompts in blockquotes (\"Search for...\"), never\n    full tool names (`infobroker_search_web`). Show the reader how to\n    express what they want — the AI maps intent to tools. Every demo\n    prompt SHALL be a valid natural-language command the reader could\n    actually run; broken prompts are a README defect.\n\n  Structure: Hero → North Star → Quick Start → MCP Server (§3 features) →\n    Skills → Providers → Configuration → How It Compares → Contribute →\n    License → Spec. No other ordering. Canonical h2 headings are enforced\n    by validate-readme. A TOC listing the canonical h2 sections follows the\n    Hero; validate-readme enforces TOC↔heading sync.\n\n  Audience split: §2 is for developers who want to start the server.\n    §3 describes what users can do with it. The Skills section (§3.5)\n    describes the bundled client skills and instructions. §4-5 are\n    configuration. §6 is competitive context. §7-9 are\n    contributor/license/spec.\n\n  Skills section: Prose only — no tables, no blockquotes, no feature\n    bullet lists. Lists the six bundled skills and the workflow shapes the\n    orchestrator routes to, with analysis-loop as the escalation shape.\n    Cross-links to the skill references (pipeline-map.md, workflows.md).\n\n  No repetition. One story vector per section. Don't explain the same\n    concept in two places — the validator flags near-duplicate sentences.\n    No feature bullet lists in prose. No tables for feature descriptions.\n\n  Feature blurbs: Each h3 under §3 follows a four-beat cadence —\n    benefit hook, mechanics, competitive proof, closer. The\n    competitive-proof sentence contrasts Infobroker against the\n    current tool landscape without naming individual competitors; it\n    answers \"why this beats what you're used to.\"\n\n  MCP server order: Features under §3 follow a research workflow —\n    Search → Extract → Verify → Write → Manage. New features\n    insert at the workflow point they serve; reorder the section\n    to restore the workflow after every addition or removal.\n\n  Comparison table: Three columns (Tool name | What you're used to |\n    How Infobroker differs). One row per competitor category, never\n    individual products. Prose paragraph below synthesizes the table;\n    it never repeats a row's content verbatim.\n\n  Hero: Exactly three elements — h1 heading, bold tagline, one prose\n    paragraph. No sub-headings, bullet lists, or preamble paragraphs.\n    The tagline uses short declarative fragments separated by periods\n    — never a sentence or question. Enforced maximum 200 words\n    (validate-readme). The tagline \"One server. Every source. Research\n    that delivers.\" is the repeated refrain — it appears exactly twice,\n    in the Hero tagline and the comparison closing prose, and no more.\n    The hero paragraph closes with \"Free first. Privacy always.\" —\n    distinct from the tagline. Updating any repeated line requires\n    updating its echo.\n\n  North Star: Single paragraph stating the Bothan Spynet metaphor and\n    intelligence-cycle framing. No sub-headings, lists, or blockquotes.\n    Maximum 100 words (enforced by validate-readme).\n\n  Tables. Exactly two tables: the Providers table (§4) and the\n    Comparison table (§6). No other tables. The Providers table lists\n    every configured provider (excluding the `native_fetch` fallback\n    renderer) — one row per provider, matching config.json.\n\n  Word budget. Hero ≤ 200 words. North Star ≤ 100 words. Each §3 feature\n    h3 ≤ 350 words. The validator's section-length check enforces these.\n\n  Non-goals. The README is not an API reference, a tool catalog, a spec\n    document, or a changelog. The complete tool inventory lives in the\n    feature taxonomy (§D of infobroker.md), which the README links to.\n    Tool names appear in prose only as shorthand in backticks where a\n    feature is introduced (e.g. `manage_kb`), never as a bare list.\n\n  Validator. Rules marked \"(validate-readme)\" SHALL be checked by\n    scripts/validate-readme.ts. Other rules are enforced by author/AI\n    discipline. Adding an enforceable rule requires a corresponding\n    validator check. Tool and provider names are derived from\n    src/index.ts and config.json at validate time — never hardcoded.\n\n  Binary style checklist (applies to every AI edit of this file):\n    1. Second person (\"you\"), never first-person.\n    2. Tool names in backticks, shorthand form; full `infobroker_`\n       prefixes only in the design comment's \"never do this\" example.\n    3. Blockquotes only in §3 feature subsections, 2-5 natural-language\n       prompts each, no tool names.\n    4. Tagline refrain \"One server. Every source. Research that\n       delivers.\" appears exactly twice (Hero + comparison closing).\n    5. No bullet list of features in prose.\n    6. Exactly two tables (Providers, Comparison), no others.\n    7. Every numeric claim reconciles to src/index.ts + config.json.\n    8. ATX headings only, no setext.\n    9. One story vector per section, no near-duplicate sentences.\n   10. \"Last updated: YYYY-MM-DD.\" matches package.json version date.\n-->\n\n# Infobroker\n\n**One server. Every source. Research that delivers.**\n\nInfobroker is a multi-provider MCP server that unifies web search,\nstructured knowledge, academic, archive, and content-extraction APIs\nbehind a single tool surface. Twenty-one zero-config providers ship in the\nbox — search the web, look up facts, fetch articles — with nothing to\nconfigure. Five more providers unlock with API keys or self-hosting. A built-in corroboration engine cross-references independent\nsources to separate established facts from contested claims. Bundled\nclient skills transform raw research into polished writing. Free first.\nPrivacy always.\n\n[![infobroker MCP server](https://glama.ai/mcp/servers/flukeatzerocool/infobroker/badges/card.svg)](https://glama.ai/mcp/servers/flukeatzerocool/infobroker)\n\n- [North Star](#north-star)\n- [Quick Start](#quick-start)\n- [MCP Server](#mcp-server)\n- [Skills](#skills)\n- [Providers](#providers)\n- [Configuration](#configuration)\n- [How It Compares](#how-it-compares)\n- [Contribute](#contribute)\n- [License](#license)\n- [Spec](#spec)\n\n## North Star\n\nInfobroker is the [Bothan Spynet](https://starwars.fandom.com/wiki/Bothan_Spynet/Legends) as a tool — a decentralized intelligence\nnetwork that queries independent sources and routes results through a\nsingle, impartial interface. In intelligence-cycle terms, you supply the\ndirection and get the dissemination; the server handles the collection and\nprocessing.\n\n## Quick Start\n\n```sh\ncd Infobroker && npm install && npm run start\n```\n\nAdd this to your OpenCode config (`~/.config/opencode/opencode.json`):\n\n```json\n{\n  \"instructions\": [\n    \"<path-to-Infobroker>/instructions/search-preferences.md\"\n  ],\n  \"skills\": {\n    \"paths\": [\n      \"<path-to-Infobroker>/skills\",\n      \"<path-to-opencode-config>/skills\"\n    ]\n  },\n  \"mcp\": {\n    \"infobroker\": {\n      \"type\": \"local\",\n      \"command\": [\"node_modules/.bin/tsx\", \"src/index.ts\"],\n      \"cwd\": \"<path-to-Infobroker>\",\n      \"environment\": {\n        \"INFOBROKER_CONFIG\": \"<path-to-Infobroker>/config.json\"\n      }\n    }\n  }\n}\n```\n\nThe `mcp` block starts the server; the `instructions` and `skills` blocks\nare what activate the bundled client skills. Without them the skills ship\nin the repository but stay inert.\n\nFree providers work immediately. API-keyed providers — Brave, Exa,\nTavily, Yep — unlock higher throughput and specialized search; self-hosted\nSearXNG gives full query privacy:\n\n```bash\nexport INFOBROKER_BRAVE_API_KEY=\"your-key\"\nexport INFOBROKER_EXA_API_KEY=\"your-key\"\n```\n\nRequirements: Node.js 20+.\n\n## MCP Server\n\nYour research backend. Seven tools, twenty-six providers, one\ncorroboration engine. The complete feature inventory is documented in the\n[feature taxonomy](infobroker.md#d-appendix-feature-taxonomy) in the\nspec.\n\n### Unified Search\n\n> \"Search for the location of the second Death Star.\"\n> \"Find scholarly papers on hyperspace travel theories.\"\n> \"Search the latest astromech specs and show me the passages that answer: does the R2 unit pre-date the Clone Wars?\"\n\n`search_web` sends one query to every provider that can answer it. Search\nacross DuckDuckGo, Wikipedia, academic databases, news, code repositories —\nor describe your task and the server picks the best source. Pass an array of\nqueries to batch several searches in one call. Ask for a deep read and it\nfetches the top results and ranks each page's passages against your query,\nso you get the specific text that answers the question instead of links.\nFailed providers fall back silently through a configurable chain so you get\nresults, not error messages. Other search tools lock you to one engine;\nInfobroker routes every query to the right provider and keeps going when one\nfails.\n\n### Content Extraction\n\n> \"Fetch the article on the Battle of Yavin and summarize it.\"\n> \"Get the text of that page about the Death Star plans.\"\n> \"Where, in that report, does it mention the reactor core?\"\n\n`fetch_page` hands any URL to Jina Reader, which renders it as clean\nMarkdown optimized for LLM consumption. Falls back to native HTTP when\nJina is throttled. Wikipedia and Internet Archive have dedicated\nrenderers for source-specific extraction. Ask a page a question — pass\n`question` to `fetch_page` and it returns the passages that answer it, each\nscored and ranked, instead of the whole document. Built-in web fetchers\nreturn raw HTML; Infobroker gives you clean, readable content from any\nsource — ready for summarization or analysis. Fetch also reports the page's\nlast-updated date when it can determine one, so you know how current your\nsource is.\n\n### Citations\n\n> \"Give me BibTeX references for papers on hyperdrive field dynamics.\"\n\n`get_citations` searches scholarly sources and returns each reference as a formatted\nBibTeX entry with its fields — title, authors, year, venue, and URL — ready\nto paste into a reference list.\n\n### Provider Intelligence\n\n> \"Which source should I use to research the Death Star's weakness?\"\n> \"Show me all available sources and their quota status.\"\n\nThe server knows its own capabilities. `search_web` auto-selects the\nbest backend for your task, weighing capability, quota, and latency —\nor routes by your intent when you ask for privacy, speed, or free-only\nsources. `inspect_providers` surfaces every configured source and drills into a\nsingle provider's uptime and error history. No other search MCP server\ngives you operational visibility into every backend.\n\n### Multi-Source Verification\n\n> \"Verify whether the Empire really destroyed Alderaan.\"\n> \"Find the consensus on who fired first — Han or Greedo.\"\n\n`verify_claims` runs a multi-pass truth-finding loop: broad\nsearch across your highest-authority providers — search engines,\nencyclopedias, and scholarly indexes — then claim extraction,\ncross-source reconciliation, and targeted follow-up for gaps, dispatched\nin parallel and stopping early once the truth is pinned down. Claims\ncorroborated across independent sources score high confidence, weighted\nby each source's authority; every source is bound to the claim it\nsupports. Contradictions are surfaced with all perspectives. Gaps\ntrigger refined queries that broaden to the rest of your providers. It\nalso remembers: prior findings in your knowledge base participate as\ncorroborating sources before it queries the network. You get a\nstructured report — confirmed, contested, and unverified findings — with\nsource provenance, per-source claims, and confidence scores. Every other\nsearch tool returns a list of links; Infobroker finds the truth and\ntells you how sure it is.\n\n### Knowledge Base\n\n> \"Search what you already found about the Rebel Alliance fleet.\"\n> \"Ingest this article so it's cached for next time.\"\n\nEvery search, fetch, and corroboration run is cached in a local knowledge\nbase. `manage_kb` checks the cache before hitting external providers — only\nfalling back to the network when the cached results aren't fresh enough\nor relevant enough. Its actions ingest new text or a URL by hand, report\nwhat's cached, and remove content. Content is age-scored, expired on a\nfreshness schedule, and deduplicated by source. Beyond the cache, `manage_kb`\narchives the reports you generate: ingest with `source_type: \"report\"`\n(and default to the knowledge base) and revisit them with `manage_kb` list and\n`manage_kb` get, or write them to a local directory instead. Each archived report\nrecords its source's last-updated date, so you can compare it against the\nlive source and refresh only what has actually changed. Other search MCP\nservers re-fetch the same facts every session; Infobroker remembers and\nreuses what it already found.\n\n### Research Pipeline\n\n> \"Research the construction of the Death Star, then draft a summary.\"\n> \"Fact-check these claims about Darth Vader's origin.\"\n\nInfobroker doesn't stop at search results. Bundled client skills chain\nits tools into writing pipelines, routing every request through a solved\nworkflow shape and the writing sub-skills until a finished document comes\nout the other end. Everything lives in the repository — no external paths\nor separate install. The full pipeline — the six skills, the workflow\nshapes, and the escalation path — is detailed in the [Skills\nsection](#skills). Other search MCP servers produce search results;\nInfobroker produces finished work.\n\n### Operational Visibility\n\n> \"Show server health.\"\n> \"Hot-reload my config without restarting.\"\n\nQuota counters persist to disk and survive restarts. Rate limits are\nenforced per-provider, not globally. Configuration is hot-reloadable\nvia `reload_config` — change providers, adjust chains, or tweak\nthresholds without dropping connections. `search_web` doubles as\nDuckDuckGo query autocomplete. `inspect_providers` reports the server's build\nhealth and request stats. You always know what your search server is\ndoing and how much capacity remains.\n\n## Skills\n\nThe MCP server is one half of the product. The bundled skills are the\nother. Six client skills ship in the repository — no external dependency,\nno separate install — and they turn raw research into finished work.\n\nThe orchestrator skill (`infobroker`) opens with a classify gate that\nmaps your request to a workflow shape: research-and-write, fact-check,\ndeep-dive, competitive evaluation, literature review, monitoring,\nred-team, vetting, or gated analysis. Each shape composes the same\nprimitives — recall from the knowledge base, search, extract, verify,\nwrite, and cite — into its own sequence and ends with a grep-able\ncompletion token so you can confirm the outcome. Four writing sub-skills\nexecute the writing phases: `summarization` condenses findings before\nwriting, `technical-writing` drafts reports and docs, `proofreading`\npolishes language, and `translation` produces multilingual output.\n\nGated analysis is the escalation shape. When a question is high-stakes or\ndecision-driving, the classify gate routes to the `analysis-loop` skill —\na disciplined path with confidence-scored findings, source-reliability\ngrading, and structured analytic techniques chosen by fit and named with a\nrationale — rather than the lighter research-and-write route. It shares the\nsame primitives and Infobroker tools but runs its own gated workflow, so you\nget the rigor without leaving the pipeline.\n\nA single instruction file, `search-preferences.md`, routes your client\ntoward these tools: the knowledge base first, external providers only\nwhen the cache falls short. Wire it and the skills directory into your\nOpenCode config once — the Quick Start above shows the exact snippet —\nand every research request follows the pipeline automatically.\n\nWrite your own skill into `skills/` to add a workflow shape of your own.\nThe pipeline diagram lives in `references/pipeline-map.md` and the\nworkflow-shape definitions in `references/workflows.md`. Other search MCP\nservers return links; Infobroker ships the writers that turn them into\ndocumented answers.\n\n## Providers\n\nTwenty-six providers. Twenty-one work with zero configuration.\n\n| Provider | Tier | Type | Key Required |\n|----------|------|------|-------------|\n| DuckDuckGo | Built-in | Web search | No |\n| Jina Reader | Free HTTP | Content extraction | No |\n| Wikipedia | Free HTTP | Encyclopedia | No |\n| Wiktionary | Free HTTP | Dictionary | No |\n| Wikidata | Free HTTP | Structured facts | No |\n| OpenStreetMap | Free HTTP | Geocoding | No |\n| Internet Archive | Free HTTP | Historical | No |\n| arXiv | Free HTTP | Academic | No |\n| Semantic Scholar | Free HTTP | Academic | Optional |\n| Stack Exchange | Free HTTP | Code Q&A | Optional |\n| GitHub | Free HTTP | Code search | Optional |\n| CORE | Free HTTP | Open access | Optional |\n| OpenAlex | Free HTTP | Academic | No |\n| Europe PMC | Free HTTP | Academic | No |\n| Hacker News | Free HTTP | News | No |\n| GDELT | Free HTTP | News | No |\n| SEC EDGAR | Free HTTP | Financial filings | No |\n| World Bank | Free HTTP | Economic data | No |\n| Marginalia | Built-in | Small web | No |\n| Mojeek | Built-in | Independent index | No |\n| Wiby | Built-in | Small web | No |\n| Brave Search | Keyed HTTP | Web, News | Yes |\n| Exa | Keyed HTTP | Semantic | Yes |\n| Tavily | Keyed HTTP | Synthesis | Yes |\n| Yep | Keyed HTTP | Web, Semantic | Yes |\n| SearXNG | Self-hosted | Full privacy | Yes (self) |\n\nBuilt-in and free-HTTP providers are active out of the box. Keyed\nproviders enable with an API key. Self-hosted providers point at a server\nyou run yourself:\n\n```bash\nexport INFOBROKER_BRAVE_API_KEY=\"BSA-...\"\nexport INFOBROKER_SEARXNG_URL=\"http://localhost:8080\"\n```\n\nThen set `\"enabled\": true` in `config.json` for the provider.\n\nSearXNG is the only shipped self-hosted provider, and it is optional\nthrough and through. Nothing in the server requires it, and nothing is\nbundled or installed on its behalf — SearXNG runs as a container you\noperate, and Infobroker queries its JSON endpoint like any other backend.\nLeave it disabled (the default) and you lose nothing: the\nprivacy-critical chain still serves via DuckDuckGo and Mojeek. Enable it\nonly when you want full query privacy, in which case only your own\nSearXNG instance sees your queries.\n\n## Configuration\n\n| Variable | Purpose |\n|----------|---------|\n| `INFOBROKER_CONFIG` | Path to config.json (default: `./config.json`) |\n| `INFOBROKER_CONFIG_LOCAL` | Optional path to a user config layer (default: `config.local.json`) |\n| `INFOBROKER_<NAME>_API_KEY` | API key for keyed providers |\n| `INFOBROKER_<NAME>_URL` | URL for self-hosted providers |\n\n`config.json` ships with the repository and holds the defaults: which\nproviders are enabled, their priority in fallback chains, rate limits,\ncorroboration parameters, and the task-to-provider dispatch table.\nHot-reloadable via `reload_config` — edit the file, call the tool, and\nchanges take effect without a restart.\n\nYour own overrides live in a separate user layer — `config.local.json`\nin the project directory (or a path you set via `INFOBROKER_CONFIG_LOCAL`).\nThis file is git-ignored, so pulling updates from the repository never\noverwrites your settings. Values in the user layer take precedence over\nthe shipped defaults; anything left out falls back to `config.json`.\n\nThe knowledge base ships empty. By default it writes to a user-scoped\npath (`~/.local/share/infobroker/knowledge-base`) outside the repository,\nso the content you research and cache stays on your machine and is never\ncommitted. Each deployed instance accumulates its own store.\n\n### Knowledge base encryption\n\nResearch reports and cached pages can be sensitive, and the knowledge\nbase stores them in a single file in your home directory. Enable optional\nat-rest encryption by adding a `kb.encryption` block and supplying a key:\n\n```json\n{\n  \"kb\": {\n    \"encryption\": { \"enabled\": true, \"key_file\": \"~/.config/infobroker/kb.key\" }\n  }\n}\n```\n\nThe key file (plain, 0600) is the most reliable source across MCP clients\nand operating systems; `INFOBROKER_KB_KEY` (a 32-byte key) or\n`INFOBROKER_KB_PASSPHRASE` (a passphrase) also work. Generate a key with\n`openssl rand -base64 32`. Encryption protects the store and disk-saved\nreports from anyone who obtains the files without the key — device theft,\nbackup or cloud-sync leaks, other local accounts. It does not protect\nagainst a malicious MCP client on the same machine, or malware, which\nfull-disk encryption covers.\n\nTwo rules keep this safe. First, encryption is your opt-in: if the key is\nmissing or wrong, the knowledge base locks and reports an error rather\nthan touching your data — so back up the key (a forgotten key or\npassphrase means the store is unrecoverable by design). Second, the server\nnever writes a partial file: every save is atomic, and an unrecognized or\nnewer store format is never overwritten.\n\nThe `manage_kb` tool's `encryption` action is the day-to-day surface for this\njourney, and it never echoes secret material — `generate_key` and `backup`\nreturn file paths, and `rekey` reads a key file rather than a raw key.\n\n**Enable** by generating a key, backing it up, adding the `kb.encryption`\nblock, and reloading; the store is encrypted in place immediately.\n**Disable** by removing the block and reloading; the store is decrypted to\nplaintext immediately (keep the key available during the transition so the\nserver can read the store to decrypt it). **Recover** a locked store with\n`status` to see the state, `verify` to confirm a candidate key before\ncommitting it, `backup` to restore a copy of your key file, and `rekey` to\nmove to a new key without losing content. After re-keying, point\n`kb.encryption.key_file` at the new key, reload, then run `verify` again to\nconfirm the new key opens the store.\n\n```\ninfobroker_manage_kb action=encryption operation=generate_key key_file=~/.local/share/infobroker/keys/kb.key\ninfobroker_manage_kb action=encryption operation=backup    key_file=~/.local/share/infobroker/keys/kb.key.bak\ninfobroker_reload_config\n```\n\nTool-surface key operations (`generate_key`, `backup`, `rekey`'s target)\nare confined to the keys directory: `kb.keys_dir` when configured, else the\n`keys` sibling of the knowledge base storage path\n(`~/.local/share/infobroker/keys` by default). A path outside that\ndirectory is refused. The `kb.encryption.key_file` *configuration* value is\noperator-owned and not subject to the confinement.\n\nAdd the `kb.encryption` block to `config.local.json` before reloading to\nenable, or remove it before reloading to disable. When the store is locked,\n`status`, `verify`, and `rekey` remain reachable so you can recover without\nfirst unlocking.\n\n### Content policy\n\nInfobroker reads the open web and caches what it retrieves, so retrieved\ncontent is assessed against a configurable policy before it is stored (and,\nin the strictest mode, before it is returned). The policy flags content\nthat matches heuristic categories — prompt-injection instructions,\ncredential phishing, malware/exploit material, and adult content — and can\nconsult an external assessment service when one is configured. It is on by\ndefault in `flag` mode: flagged content is still returned to you for\nlegitimate research, but it is never written to the knowledge base, and\nevery flag is recorded in the audit trail.\n\n```json\n{\n  \"content_policy\": {\n    \"mode\": \"flag\",\n    \"threshold\": 0.2,\n    \"patterns\": { \"prompt_injection\": [\"ignore previous instructions\"] }\n  }\n}\n```\n\nModes: `off` disables assessment; `flag` (default) returns but never stores\nflagged content; `block` refuses flagged content to the caller. `threshold`\ntunes sensitivity (0–1, default 0.2 — a single match flags). `patterns`\nextend or override the built-in categories per category name. `external_url_env`\nnames an environment variable holding the URL of an external assessor, and\n`external_api_key_env` optionally names one holding its bearer key; when the\nexternal service is unreachable the built-in assessment applies.\n\nSecurity-relevant events — refused network targets, policy flags, config\nreloads, encryption transitions, key operations, and quota exhaustion — are\nappended to an owner-only audit log at `output.audit_log_path` (default\n`~/.local/share/infobroker/audit.log`).\n\n### Bring your own endpoint\n\nAny HTTP search endpoint can become an Infobroker provider without\ntouching the source tree. Declare it in `config.local.json` as a\n`generic_http` provider, then reference it from a dispatch chain:\n\n```json\n{\n  \"providers\": {\n    \"my_search\": {\n      \"tier\": \"generic_http\",\n      \"capabilities\": [\"web_search\"],\n      \"enabled\": true,\n      \"priority\": 20,\n      \"endpoint\": \"https://api.example.com/search\",\n      \"query_param\": \"q\",\n      \"results_path\": \"data.items\",\n      \"field_map\": { \"title\": \"name\", \"url\": \"link\", \"snippet\": \"summary\" }\n    }\n  },\n  \"dispatch\": { \"general_web\": [\"my_search\", \"duckduckgo\"] }\n}\n```\n\nThe server GETs `endpoint?query_param=<query>`, walks `results_path`\n(dot-separated into the response JSON), and maps each result to the\ncommon shape using `field_map`. Add the slug to your `config.local.json`\noverride and call `reload_config` to use it immediately.\n\n### Per-provider status and provenance\n\nTwo optional keys tune per-provider behavior in `config.json`:\n\n- `degraded_latency_ms` — a provider whose recent average latency exceeds\n  this many milliseconds is reported `degraded` by the `inspect_providers` health\n  action, even while reachable. A global `output.degraded_latency_ms` acts\n  as the fallback when a provider omits its own.\n- `resells` — set `true` on aggregator/reseller backends (search engines\n  that surface other publishers' pages, like DuckDuckGo, Brave, or\n  SearXNG). The server reports each result's `original_source` where the\n  backing API exposes one (e.g. Brave's `profile` name); first-party\n  sources (Wikipedia, arXiv) leave it empty because the page is the\n  origin.\n\n### Hedged fallback\n\n`search_web` and `fetch_page` fall back with a hedge instead of waiting\nout a slow provider's full timeout: the primary (first-choice) provider\nruns alone for a latency-derived window, then the remaining providers\nrace and the first result wins. The common path uses one provider call;\nthe hedge fires only when the primary is slow or failing. `fetch_page`\nadditionally prefers the primary renderer in a short grace window so a\nmarginally slow `jina` is not displaced by a lower-quality `native_fetch`.\nA renderer whose content is an anti-bot challenge page (a CAPTCHA or\nverification interstitial rather than the target page) is treated as a\nfailed render, so `fetch_page` falls through to the next renderer instead\nof serving the challenge as content.\nTune the window with `output.hedge_enabled`, `hedge_min_delay_ms`,\n`hedge_max_delay_ms`, and `hedge_grace_ms`; set `hedge_enabled` to\n`false` for the sequential chain. A provider that returns a rate-limit\nor anti-bot response is held in a per-provider cooldown (`output.rate_limit_cooldown_ms`)\nso a burst of requests stops re-hammering it, and when a non-`general_web`\nchain exhausts, the server retries the `general_web` chain before failing.\n\n## How It Compares\n\n| Tool name | What you're used to | How Infobroker differs |\n|-----------|--------------------|-----------------------|\n| Built-in `websearch` / `webfetch` | One search engine, one fetch mode, no configuration, no visibility into what backend is used | Twenty-one zero-config providers with a unified tool surface. Choose the right source for each task. Fall back automatically on failure. See every provider's status and quota. |\n| Raw API calls | Manual HTTP requests, per-provider auth, per-provider response parsing, no fallback, no quota tracking | One interface for every provider. API keys configured once. Results normalized to a common shape. Rate limits and quota tracked automatically. |\n| Dedicated search APIs | Pay-per-query, vendor lock-in, opaque routing | Free-first design. DuckDuckGo, Wikipedia, and nineteen other providers work with zero configuration. Upgrade paths for Brave, Exa, Tavily, and Yep. Self-hosted SearXNG for full privacy. |\n| Other search MCP servers | Single-provider focus, no fallback, no corroboration, no writing pipeline | Multi-provider with automatic fallback. Corroboration engine cross-references independent sources. Bundled writing skills transform research into finished documents. |\n| AI with built-in search | The model picks the search engine, serves stale cache, no reproducibility | You control the provider chain. Queries are reproducible. Fallback behavior is visible. The corroboration engine verifies facts across independent sources. |\n\nEvery other search MCP server asks you to pick a provider and trust it.\nInfobroker gives you a fleet — and picks the right one for each task.\nWhen a provider fails, the next one takes over without you noticing.\nWhen a claim matters, the corroboration engine finds agreement,\ncontradiction, and gaps. The bundled skills close the loop from raw\nresearch to finished writing. One server. Every source. Research that\ndelivers.\n\nLast updated: 2026-09-06.\n\n## Contribute\n\n- **Node.js 20+.** `node --version`. Get it at\n  [nodejs.org](https://nodejs.org).\n- `npm install && npm run typecheck`\n- Bundle your own skill in `skills/` to extend the research pipeline.\n- Validate README structure: `npm run validate-readme`\n- **Versioning:** CalVer (`YYYY.MM.DD`). `npm run version-bump` stamps\n  today's date into all version references. Pre-commit hooks verify\n  consistency. `npm run push` checks, tags, and pushes.\n- MCP protocol: [modelcontextprotocol.io](https://modelcontextprotocol.io)\n- Providers: [DuckDuckGo](https://duckduckgo.com) ·\n  [Jina Reader](https://jina.ai/reader) ·\n  [Wikipedia API](https://en.wikipedia.org/w/api.php)\n\nCanonical origin: [git.gay/flukeatzerocool/Infobroker](https://git.gay/flukeatzerocool/Infobroker). This GitHub repository is a read-only mirror.\n\n## License\n\nMIT. Free to use, modify, and redistribute. The bundled client skills and\ninstruction files ship under the same license, so the full research pipeline\n— server, skills, and documentation — is freely reusable in commercial and\nopen-source work alike. Third-party providers remain subject to their own\nterms and API keys.\n\n## Spec\n\nThe server is built from a single source specification, `infobroker.md`\n(v2026.09.06), which defines every requirement and the gates that verify it.\nEach requirement traces to an implementation file, and `npm run check`\nreconciles the code, the spec, and this README so what is documented is what\nthe server actually delivers.\n",
  "bytes": 31356,
  "sha": "eb2eee53594fc5f80d3a4da1603a89d230606b28eed6ff88db6d5223c50ff49b",
  "repo_slug": "flukeatzerocool/infobroker",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_flukeatzerocool_infobroker_081497c7/readme"
}