Infobroker
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| INFOBROKER_CONFIG | No | Path to config.json (default: ./config.json) | ./config.json |
| INFOBROKER_KB_KEY | No | Optional 32-byte key for knowledge base encryption. Alternative to INFOBROKER_KB_PASSPHRASE or kb.encryption.key_file in config. | |
| INFOBROKER_EXA_API_KEY | No | API key for Exa (keyed provider). Set to enable. | |
| INFOBROKER_SEARXNG_URL | No | URL for self-hosted SearXNG server (e.g., http://localhost:8080). Required only if enabling SearXNG. | |
| INFOBROKER_YEP_API_KEY | No | API key for Yep (keyed provider). Set to enable. | |
| INFOBROKER_CONFIG_LOCAL | No | Optional path to a user config layer (default: config.local.json) | config.local.json |
| INFOBROKER_BRAVE_API_KEY | No | API key for Brave Search (keyed provider). Set to enable. | |
| INFOBROKER_KB_PASSPHRASE | No | Optional passphrase for knowledge base encryption. Alternative to INFOBROKER_KB_KEY or kb.encryption.key_file in config. | |
| INFOBROKER_TAVILY_API_KEY | No | API key for Tavily (keyed provider). Set to enable. |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| infobroker_search_web | Search the web, encyclopedia, academic, and code sources through one interface with automatic provider selection and a fallback chain. Use when you need broad or batched search, query autocomplete (suggest), query expansion (expand), ranked passages from the top pages (deep), or a multi-variant research compile that deep-reads each variant (research), and optional in-process analysis of the returned results (analyze: topics, entities, clusters, timeline). Do NOT use for a URL you already have (use infobroker_fetch_page), for high-stakes claim verification (use infobroker_verify_claims), for stored-report recall (use infobroker_manage_kb search), or for academic citations (use infobroker_get_citations). Caches results in the local knowledge base, enforces per-provider rate limits, and needs no API key for the free providers. |
| infobroker_fetch_pageA | Fetch a URL and extract clean content via a renderer (Jina Reader by default; native-HTTP, Wikipedia, Internet Archive, arXiv, and Stack Exchange alternatives). Use when you have a URL and need readable text, passages ranked against a question, or the page's last-updated date. Do NOT use for topic search (use infobroker_search_web) or cross-source claim verification (use infobroker_verify_claims). |
| infobroker_inspect_providers | Inspect configured search providers: list their state, run a live health check, or report build and spec identity. Use when searches return empty or slow results and you want provider status, quota, or latency, or when choosing which backend to trust. Do NOT use to search (use infobroker_search_web) or to read a page (use infobroker_fetch_page). Read-only: it never modifies configuration, providers, or stored data. |
| infobroker_verify_claimsA | Verify a contested claim against independent sources and return confidence-scored findings. Use when a claim is high-stakes or contested and you need agreement, contradiction, and gaps surfaced with confidence scores. Do NOT use for simple lookups or broad search (use infobroker_search_web) or citation formatting (use infobroker_get_citations). The loop recalls prior findings from the knowledge base, then searches providers and writes findings back; |
| infobroker_manage_kb | Manage the local knowledge base: search cached content, ingest text or URLs, list/get/delete entries, view stats, read persisted claim records, and manage at-rest encryption. Use when you need to archive a generated report (ingest with source_type 'report' and save_to 'kb'), revisit stored content, or manage encryption keys. Do NOT use for fresh external search (use infobroker_search_web) or to fetch a new page (use infobroker_fetch_page). The delete action is destructive and cannot be undone; a lost encryption key makes the store unrecoverable by design. Parameter semantics: |
| infobroker_reload_configA | Re-read the configuration file and apply provider, rate-limit, and knowledge-base changes without restarting; active connections are preserved. Use when you have edited config.json or config.local.json, or when passing |
| infobroker_get_citationsA | Return academic references for a query as BibTeX citations with title, authors, year, venue, and URL. Use when scholarly writing needs a reference list. Do NOT use for general web search (use infobroker_search_web) or contested-claim verification (use infobroker_verify_claims). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a clearly distinct role, and the descriptions explicitly cross-reference alternatives (e.g. search_web vs fetch_page vs verify_claims vs get_citations). The only potential overlaps — KB search vs web search, provider inspection vs config reload — are sharply bounded by stored-vs-fresh and read-only-vs-mutating semantics.
All tools use the same infobroker_ prefix followed by a consistent snake_case verb_noun pattern: get_citations, fetch_page, inspect_providers, manage_kb, reload_config, search_web, verify_claims. There is no mixing of casing or verb styles.
Seven tools is well within the appropriate range for a research/information-broker server. Each tool earns its place by covering a distinct workflow stage: discovery, retrieval, citation, verification, storage, diagnostics, and configuration.
The surface covers the core research lifecycle: search, page fetch, citation generation, claim verification, knowledge-base storage/recall, provider inspection, and config reload. Minor gaps exist, such as no explicit update/edit action for existing KB entries beyond ingest, but agents can work around this.