Infobroker is a multi-provider MCP server that unifies web search,
structured knowledge, academic, archive, and content-extraction APIs
behind a single tool surface. Twenty-one zero-config providers ship in the
box — search the web, look up facts, fetch articles — with nothing to
configure. Five more providers unlock with API keys or self-hosting.
A built-in corroboration engine cross-references independent sources to
separate established facts from contested claims. Bundled client skills
transform raw research into polished writing. Free first. Privacy always.
Multi-provider research MCP server: unified web search, fact-checking, personal knowledge base.
Infobroker is the Bothan Spynet as a tool — a decentralized intelligence
network that queries independent sources and routes results through a
single, impartial interface. In intelligence-cycle terms, you supply the
direction and get the dissemination; the server handles the collection and
processing.
Quick Start
cd Infobroker && npm install && npm run start
Add this to your OpenCode config (~/.config/opencode/opencode.json):
The mcp block starts the server; the instructions and skills blocks
are what activate the bundled client skills. Without them the skills ship
in the repository but stay inert.
Free providers work immediately. API-keyed providers — Brave, Exa,
Tavily, Yep — unlock higher throughput and specialized search; self-hosted
SearXNG gives full query privacy:
Your research backend. Seven tools, twenty-six providers, one
corroboration engine. The complete feature inventory is documented in the
feature taxonomy in the
spec.
Unified Search
"Search for the location of the second Death Star."
"Find scholarly papers on hyperspace travel theories."
"Search the latest astromech specs and show me the passages that answer: does the R2 unit pre-date the Clone Wars?"
search_web sends one query to every provider that can answer it. Search
across DuckDuckGo, Wikipedia, academic databases, news, code repositories —
or describe your task and the server picks the best source. Pass an array of
queries to batch several searches in one call. Ask for a deep read and it
fetches the top results, then ranks each page's passages against your query,
so you get the specific text that answers the question instead of links.
Failed providers fall back silently through a configurable chain so you get
results, not error messages. Other search tools lock you to one engine;
Infobroker routes every query to the right provider and keeps going when one
fails.
Content Extraction
"Fetch the article on the Battle of Yavin and summarize it."
"Get the text of that page about the Death Star plans."
"Where, in that report, does it mention the reactor core?"
fetch_page hands any URL to Jina Reader, which renders it as clean
Markdown optimized for LLM consumption. It falls back to native HTTP when
Jina is throttled. Wikipedia and Internet Archive have dedicated
renderers for source-specific extraction. Ask a page a question — pass
question to fetch_page and it returns the passages that answer it, each
scored and ranked, instead of the whole document. Built-in web fetchers
return raw HTML; Infobroker gives you clean, readable content from any
source — ready for summarization or analysis. Fetch also reports the page's
last-updated date when it can determine one, so you know how current your
source is.
Citations
"Give me BibTeX references for papers on hyperdrive field dynamics."
"Cite the paper that first described the hyperdrive field equations."
get_citations searches scholarly sources and returns each reference as a formatted
BibTeX entry with its fields — title, authors, year, venue, and URL — ready
to paste into a reference list.
Provider Intelligence
"Which source should I use to research the Death Star's weakness?"
"Show me all available sources and their quota status."
The server knows its own capabilities. search_web auto-selects the
best backend for your task, weighing capability, quota, and latency —
or routes by your intent when you ask for privacy, speed, or free-only
sources. inspect_providers surfaces every configured source and drills into a
single provider's uptime and error history. No other search MCP server
gives you operational visibility into every backend.
Multi-Source Verification
"Verify whether the Empire really destroyed Alderaan."
"Find the consensus on who fired first — Han or Greedo."
verify_claims runs a multi-pass truth-finding loop: broad
search across your highest-authority providers — search engines,
encyclopedias, and scholarly indexes — then claim extraction,
cross-source reconciliation, and targeted follow-up for gaps, dispatched
in parallel and stopping early once the truth is pinned down. Claims
corroborated across independent sources score high confidence, weighted
by each source's authority; every source is bound to the claim it
supports. Contradictions are surfaced with all perspectives. Gaps
trigger refined queries that broaden to the rest of your providers. It
also remembers: prior findings in your knowledge base participate as
corroborating sources before it queries the network. You get a
structured report — confirmed, contested, and unverified findings — with
source provenance, per-source claims, and confidence scores. Every other
search tool returns a list of links; Infobroker finds the truth and
tells you how sure it is.
Knowledge Base
"Search what you already found about the Rebel Alliance fleet."
"Ingest this article so it's cached for next time."
Every search, fetch, and corroboration run is cached in a local knowledge
base. manage_kb checks the cache before hitting external providers, falling
back to the network only when the cached results aren't fresh enough
or relevant enough. Its actions ingest new text or a URL by hand, report
what's cached, and remove content. Content is age-scored, expired on a
freshness schedule, and deduplicated by source. Retrieval runs on your
machine with a configurable in-process embedding model — your content is
never sent to a third party to be embedded. Beyond
the cache, manage_kb archives the reports you generate: ingest with
source_type: "report"
(and default to the knowledge base) and revisit them with manage_kb list and
manage_kb get, or write them to a local directory instead. Each archived report
records its source's last-updated date, so you can compare it against the
live source and refresh only what has actually changed. Other search MCP
servers re-fetch the same facts every session; Infobroker remembers and
reuses what it already found.
Research Pipeline
"Research the construction of the Death Star, then draft a summary."
"Fact-check these claims about Darth Vader's origin."
Infobroker doesn't stop at search results. Bundled client skills chain
its tools into writing pipelines, routing every request through a solved
workflow shape and the writing sub-skills until a finished document comes
out the other end. Everything lives in the repository — no external paths
or separate install. The full pipeline — the six skills, the workflow
shapes, and the escalation path — is detailed in the Skills
section. Other search MCP servers produce search results;
Infobroker produces finished work.
Operational Visibility
"Show server health."
"Hot-reload my config without restarting."
Quota counters persist to disk and survive restarts. Rate limits are
enforced per-provider, not globally. Configuration is hot-reloadable
via reload_config — change providers, adjust chains, or tweak
thresholds without dropping connections, or pass a patch to merge a
change into your user layer with a backup. search_web doubles as
DuckDuckGo query autocomplete. inspect_providers reports the server's build
health and request stats. You always know what your search server is
doing and how much capacity remains.
Skills
The MCP server is one half of the product. The bundled skills are the
other. Six client skills ship in the repository — no external dependency,
no separate install — and they turn raw research into finished work.
The orchestrator skill (infobroker) opens with a classify gate that
maps your request to a workflow shape: research-and-write, fact-check,
deep-dive, competitive evaluation, literature review, monitoring,
red-team, vetting, or gated analysis. Each shape composes the same
primitives — recall from the knowledge base, search, extract, verify,
write, and cite — into its own sequence and ends with a grep-able
completion token so you can confirm the outcome. Four writing sub-skills
execute the writing phases: summarization condenses findings before
writing, technical-writing drafts reports and docs, proofreading
polishes language, and translation produces multilingual output.
Gated analysis is the escalation shape. When a question is high-stakes or
decision-driving, the classify gate routes to the analysis-loop skill —
a disciplined path with confidence-scored findings, source-reliability
grading, and structured analytic techniques chosen by fit and named with a
rationale — rather than the lighter research-and-write route. It shares the
same primitives and Infobroker tools but runs its own gated workflow, so you
get the rigor without leaving the pipeline.
A single instruction file, search-preferences.md, routes your client
toward these tools: the knowledge base first, external providers only
when the cache falls short. Wire it and the skills directory into your
OpenCode config once — the Quick Start section shows the exact snippet —
and every research request follows the pipeline automatically.
Write your own skill into skills/ to add a workflow shape of your own.
The pipeline diagram lives in references/pipeline-map.md and the
workflow-shape definitions in references/workflows.md. Other search MCP
servers return links; Infobroker ships the writers that turn them into
documented answers.
Providers
Twenty-six providers. Twenty-one work with zero configuration.
Provider
Tier
Type
Key Required
DuckDuckGo
Built-in
Web search
No
Jina Reader
Free HTTP
Content extraction
No
Wikipedia
Free HTTP
Encyclopedia
No
Wiktionary
Free HTTP
Dictionary
No
Wikidata
Free HTTP
Structured facts
No
OpenStreetMap
Free HTTP
Geocoding
No
Internet Archive
Free HTTP
Historical
No
arXiv
Free HTTP
Academic
No
Semantic Scholar
Free HTTP
Academic
Optional
Stack Exchange
Free HTTP
Code Q&A
Optional
GitHub
Free HTTP
Code search
Optional
CORE
Free HTTP
Open access
Optional
OpenAlex
Free HTTP
Academic
No
Europe PMC
Free HTTP
Academic
No
Hacker News
Free HTTP
News
No
GDELT
Free HTTP
News
No
SEC EDGAR
Free HTTP
Financial filings
No
World Bank
Free HTTP
Economic data
No
Marginalia
Built-in
Small web
No
Mojeek
Built-in
Independent index
No
Wiby
Built-in
Small web
No
Brave Search
Keyed HTTP
Web, News
Yes
Exa
Keyed HTTP
Semantic
Yes
Tavily
Keyed HTTP
Synthesis
Yes
Yep
Keyed HTTP
Web, Semantic
Yes
SearXNG
Self-hosted
Full privacy
Yes (self)
Built-in and free-HTTP providers are active out of the box. Keyed
providers enable with an API key. Self-hosted providers point at a server
you run yourself:
Then set "enabled": true in config.json for the provider.
Keyed providers also accept an ordered credential pool via
INFOBROKER_<NAME>_API_KEYS (comma-separated). Infobroker rotates to the
next key when one is rejected or rate-limited, and reports per-key
availability through inspect_providers without ever surfacing key
material.
SearXNG is the only shipped self-hosted provider, and it is optional
through and through. Nothing in the server requires it, and nothing is
bundled or installed on its behalf — SearXNG runs as a container you
operate, and Infobroker queries its JSON endpoint like any other backend.
Leave it disabled (the default) and you lose nothing: the
privacy-critical chain still serves via DuckDuckGo and Mojeek. Enable it
only when you want full query privacy, in which case only your own
SearXNG instance sees your queries.
Configuration
Four environment variables tune a deployment. INFOBROKER_CONFIG points
at a different config file (default ./config.json),
INFOBROKER_CONFIG_LOCAL at a user config layer (default
config.local.json), INFOBROKER_<NAME>_API_KEY supplies a keyed
provider's credential, and INFOBROKER_<NAME>_URL points at a self-hosted
provider.
config.json ships with the repository and holds the defaults: which
providers are enabled, their priority in fallback chains, rate limits,
corroboration parameters, and the task-to-provider dispatch table.
Hot-reloadable via reload_config — edit the file and call the tool, or
pass a patch to merge configuration programmatically; changes take
effect without a restart.
Your own overrides live in a separate user layer — config.local.json
in the project directory (or a path you set via INFOBROKER_CONFIG_LOCAL).
This file is git-ignored, so pulling updates from the repository never
overwrites your settings. Values in the user layer take precedence over
the shipped defaults; anything left out falls back to config.json.
config.json carries a schema stamp (config_version). If your user layer
was written for an older schema, or holds a key the current schema no longer
recognizes, the server reports the drift at startup and in every
reload_config response without changing your file. Apply the registered
migrations on demand by calling reload_config with migrate true: the
server first copies your layer to a timestamped *.bak-* file, then updates
it atomically, leaving anything it does not recognize untouched.
The knowledge base ships empty. Retrieval runs on a configurable in-process
embedding model selected by kb.embedding_model. By default, the store
writes to a user-scoped path (~/.local/share/infobroker/knowledge-base)
outside the repository, so the content you research and cache stays on your
machine and is never committed. Each deployed instance accumulates its own
store. kb.store_backend selects sqlite (default) or the one-release
json legacy backend; opening a legacy vector-store.json store migrates it
automatically and preserves the original as vector-store.json.migrated-<timestamp>.
Rollback to the JSON backend is available only if encryption has never been
enabled (enabling encryption removes the plaintext migration archive).
Knowledge base encryption
Research reports and cached pages can be sensitive, and the knowledge
base stores them in a SQLite database (plus -wal/-shm sidecars) in your
home directory. Enable optional
at-rest encryption by adding a kb.encryption block and supplying a key:
The key file (plain, 0600) is the most reliable source across MCP clients
and operating systems; INFOBROKER_KB_KEY (a 32-byte key) or
INFOBROKER_KB_PASSPHRASE (a passphrase) also work. Generate a key with
openssl rand -base64 32. Encryption protects the store and disk-saved
reports from anyone who obtains the files without the key — device theft,
backup or cloud-sync leaks, other local accounts. It does not protect
against a malicious MCP client on the same machine, or malware, which
full-disk encryption covers.
Two rules keep this safe. First, encryption is your opt-in: if the key is
missing or wrong, the knowledge base locks and reports an error rather
than touching your data — so back up the key (a forgotten key or
passphrase means the store is unrecoverable by design). Second, the server
never writes a partial file: every save is atomic, and an unrecognized or
newer store format is never overwritten.
The manage_kb tool's encryption action is the day-to-day surface for this
journey, and it never echoes secret material — generate_key and backup
return file paths, and rekey reads a key file rather than a raw key.
Enable by generating a key, backing it up, adding the kb.encryption
block, and reloading; the store is encrypted in place immediately.
Disable by removing the block and reloading; the store is decrypted to
plaintext immediately (keep the key available during the transition so the
server can read the store to decrypt it). Recover a locked store with
status to see the state, verify to confirm a candidate key before
committing it, backup to restore a copy of your key file, and rekey to
move to a new key without losing content. After re-keying, point
kb.encryption.key_file at the new key, reload, then run verify again to
confirm the new key opens the store.
Tool-surface key operations (generate_key, backup, rekey's target)
are confined to the keys directory: kb.keys_dir when configured, else the
keys sibling of the knowledge base storage path
(~/.local/share/infobroker/keys by default). A path outside that
directory is refused. The kb.encryption.key_fileconfiguration value is
operator-owned and not subject to the confinement.
Add the kb.encryption block to config.local.json before reloading to
enable, or remove it before reloading to disable. When the store is locked,
status, verify, and rekey remain reachable so you can recover without
first unlocking.
Content policy
Infobroker reads the open web and caches what it retrieves, so retrieved
content is assessed against a configurable policy before it is stored (and,
in the strictest mode, before it is returned). The policy flags content
that matches heuristic categories — prompt-injection instructions,
credential phishing, malware/exploit material, and adult content — and can
consult an external assessment service when one is configured. It is on by
default in flag mode: flagged content is still returned to you for
legitimate research, but it is never written to the knowledge base, and
every flag is recorded in the audit trail.
Modes: off disables assessment; flag (default) returns but never stores
flagged content; block refuses flagged content to the caller. threshold
tunes sensitivity (0–1, default 0.2 — a single match flags). patterns
extend or override the built-in categories per category name. external_url_env
names an environment variable holding the URL of an external assessor, and
external_api_key_env optionally names one holding its bearer key; when the
external service is unreachable the built-in assessment applies.
Security-relevant events — refused network targets, policy flags, config
reloads, encryption transitions, key operations, and quota exhaustion — are
appended to an owner-only audit log at output.audit_log_path (default
~/.local/share/infobroker/audit.log).
Bring your own endpoint
Any HTTP search endpoint can become an Infobroker provider without
touching the source tree. Declare it in config.local.json as a
generic_http provider, then reference it from a dispatch chain:
The server GETs endpoint?query_param=<query>, walks results_path
(dot-separated into the response JSON), and maps each result to the
common shape using field_map. Add the slug to your config.local.json
override and call reload_config to use it immediately.
Per-provider status and provenance
Two optional keys tune per-provider behavior in config.json:
degraded_latency_ms — a provider whose recent average latency exceeds
this many milliseconds is reported degraded by the inspect_providers health
action, even while reachable. A global output.degraded_latency_ms acts
as the fallback when a provider omits its own.
resells — set true on aggregator/reseller backends (search engines
that surface other publishers' pages, like DuckDuckGo, Brave, or
SearXNG). The server reports each result's original_source where the
backing API exposes one (e.g. Brave's profile name); first-party
sources (Wikipedia, arXiv) leave it empty because the page is the
origin.
Hedged fallback
search_web and fetch_page fall back with a hedge instead of waiting
out a slow provider's full timeout: the primary (first-choice) provider
runs alone for a latency-derived window, then the remaining providers
race and the first result wins. The common path uses one provider call;
the hedge fires only when the primary is slow or failing. fetch_page
additionally prefers the primary renderer in a short grace window so a
marginally slow jina is not displaced by a lower-quality native_fetch.
A renderer whose content is an anti-bot challenge page (a CAPTCHA or
verification interstitial rather than the target page) is treated as a
failed render, so fetch_page falls through to the next renderer instead
of serving the challenge as content.
Tune the window with output.hedge_enabled, hedge_min_delay_ms,
hedge_max_delay_ms, and hedge_grace_ms; set hedge_enabled to
false for the sequential chain. A provider that returns a rate-limit
or anti-bot response is held in a per-provider cooldown (output.rate_limit_cooldown_ms)
so a burst of requests stops re-hammering it, and when a non-general_web
chain exhausts, the server retries the general_web chain before failing.
How It Compares
Tool name
What you're used to
How Infobroker differs
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.
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.
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.
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.
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.
Every other search MCP server asks you to pick a provider and trust it.
Infobroker gives you a fleet — and picks the right one for each task.
When a provider fails, the next one takes over without you noticing.
When a claim matters, the corroboration engine finds agreement,
contradiction, and gaps. The bundled skills close the loop from raw
research to finished writing. One server. Every source. Research that
delivers.
Bundle your own skill in skills/ to extend the research pipeline.
Validate README structure: npm run validate-readme
Versioning: CalVer (YYYY.MM.DD). npm run version-bump stamps
today's date into all version references. Pre-commit hooks verify
consistency. npm run push checks, tags, and pushes.
MIT. Free to use, modify, and redistribute. The bundled client skills and
instruction files ship under the same license, so the full research pipeline
— server, skills, and documentation — is freely reusable in commercial and
open-source work alike. Third-party providers remain subject to their own
terms and API keys.
Spec
The server is built from a single source specification, infobroker.md
(v2026.10.22), which defines every requirement and the gates that verify it.
Each requirement traces to an implementation file, and npm run check
reconciles the code, the spec, and this README so what is documented is what
the server actually delivers. The routing gate resolves every cited tool and
operation against the live schema, and requires each registered tool to be
cited at least once.
Noch keine Tool-Liste. Remote-Server erhalten eine nach dem ersten Health-Check.
FAQ
Fragen
Wie installiere ich Infobroker?
Kopieren Sie auf dieser Seite die stdio-Konfiguration für Cursor, Claude Desktop, Claude Code oder VS Code. Sie nutzt die Installation des Herausgebers, keinen PlugMCP-Proxy.
Benötigt Infobroker einen API-Schlüssel?
Der Herausgeber nennt diese Umgebungsvariablen: INFOBROKER_EXA_API_KEY, INFOBROKER_TAVILY_API_KEY, INFOBROKER_YEP_API_KEY, INFOBROKER_SEARXNG_URL.
Welchen Transport verwendet Infobroker?
Infobroker läuft lokal über stdio.
Wann wurde Infobroker zuletzt geprüft?
Zuletzt geprüft: 2026-11-14. Multi-provider research MCP server: unified web search, fact-checking, personal knowledge base.
