# infobroker [Health: Active] **Category:** πŸ’» Developer Tools **Repository:** https://github.com/flukeatzerocool/infobroker **GitHub Stars:** 0 **npm Downloads (last month):** 1515 **Views:** 0 **Installs:** 0 **Upvotes:** 0 **Directory Page:** https://allmcps.com/mcp/infobroker ## Description Multi-provider research MCP server: unified web search, fact-checking, personal knowledge base. ## Claude Desktop Quick Installation Heuristic fallback β€” verify the package name and runner against the repository README before running it. Uses `npx` (confidence: low): ```json "mcpServers": { "infobroker": { "command": "npx", "args": ["-y","infobroker"] } } ``` ## Documentation & README # Infobroker **One server. Every source. Research that delivers.** 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. [![infobroker MCP server](https://glama.ai/mcp/servers/flukeatzerocool/infobroker/badges/card.svg)](https://glama.ai/mcp/servers/flukeatzerocool/infobroker) - [North Star](#north-star) - [Quick Start](#quick-start) - [MCP Server](#mcp-server) - [Skills](#skills) - [Providers](#providers) - [Configuration](#configuration) - [How It Compares](#how-it-compares) - [Contribute](#contribute) - [License](#license) - [Spec](#spec) ## North Star Infobroker is the [Bothan Spynet](https://starwars.fandom.com/wiki/Bothan_Spynet/Legends) 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 ```sh cd Infobroker && npm install && npm run start ``` Add this to your OpenCode config (`~/.config/opencode/opencode.json`): ```json { "instructions": [ "/instructions/search-preferences.md" ], "skills": { "paths": [ "/skills", "/skills" ] }, "mcp": { "infobroker": { "type": "local", "command": ["node_modules/.bin/tsx", "src/index.ts"], "cwd": "", "environment": { "INFOBROKER_CONFIG": "/config.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: ```bash export INFOBROKER_BRAVE_API_KEY="your-key" export INFOBROKER_EXA_API_KEY="your-key" ``` Requirements: Node.js 20+. ## MCP Server Your research backend. Seven tools, twenty-six providers, one corroboration engine. The complete feature inventory is documented in the [feature taxonomy](https://github.com/flukeatzerocool/infobroker/blob/HEAD/infobroker.md#d-appendix-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 and 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. 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." `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 β€” only falling back to the network 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. 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](#skills). 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. `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 above 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: ```bash export INFOBROKER_BRAVE_API_KEY="BSA-..." export INFOBROKER_SEARXNG_URL="http://localhost:8080" ``` Then set `"enabled": true` in `config.json` for the provider. 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 | Variable | Purpose | |----------|---------| | `INFOBROKER_CONFIG` | Path to config.json (default: `./config.json`) | | `INFOBROKER_CONFIG_LOCAL` | Optional path to a user config layer (default: `config.local.json`) | | `INFOBROKER__API_KEY` | API key for keyed providers | | `INFOBROKER__URL` | URL for self-hosted providers | `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, call the tool, and 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`. The knowledge base ships empty. By default it 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. ### Knowledge base encryption Research reports and cached pages can be sensitive, and the knowledge base stores them in a single file in your home directory. Enable optional at-rest encryption by adding a `kb.encryption` block and supplying a key: ```json { "kb": { "encryption": { "enabled": true, "key_file": "~/.config/infobroker/kb.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. ``` infobroker_manage_kb action=encryption operation=generate_key key_file=~/.local/share/infobroker/keys/kb.key infobroker_manage_kb action=encryption operation=backup key_file=~/.local/share/infobroker/keys/kb.key.bak infobroker_reload_config ``` 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_file` *configuration* 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. ```json { "content_policy": { "mode": "flag", "threshold": 0.2, "patterns": { "prompt_injection": ["ignore previous instructions"] } } } ``` 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: ```json { "providers": { "my_search": { "tier": "generic_http", "capabilities": ["web_search"], "enabled": true, "priority": 20, "endpoint": "https://api.example.com/search", "query_param": "q", "results_path": "data.items", "field_map": { "title": "name", "url": "link", "snippet": "summary" } } }, "dispatch": { "general_web": ["my_search", "duckduckgo"] } } ``` The server GETs `endpoint?query_param=`, 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. Last updated: 2026-09-06. ## Contribute - **Node.js 20+.** `node --version`. Get it at [nodejs.org](https://nodejs.org). - `npm install && npm run typecheck` - 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. - MCP protocol: [modelcontextprotocol.io](https://modelcontextprotocol.io) - Providers: [DuckDuckGo](https://duckduckgo.com) Β· [Jina Reader](https://jina.ai/reader) Β· [Wikipedia API](https://en.wikipedia.org/w/api.php) Canonical origin: [git.gay/flukeatzerocool/Infobroker](https://git.gay/flukeatzerocool/Infobroker). This GitHub repository is a read-only mirror. ## License 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.09.06), 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.