Infobroker is a multi-provider MCP server for unified research: search, extract, verify, and write — with 20 providers, fallback, corroboration, a local knowledge base, and bundled client skills.
Search across many sources at once with web_search: one query routed to the best provider, batch queries, deep-read passage ranking, autocomplete, and fallback handling.
Fetch and extract page content with fetch_page: clean Markdown via Jina Reader, native HTTP fallback, source-specific renderers, and question-answering on a page.
Get citations as BibTeX entries from scholarly sources via cite (referenced in README).
Inspect provider intelligence with providers: list sources, check health/status/quota, and see per-provider operational details.
Run multi-source verification with corroborate: cross-reference independent sources, surface confirmed/contested/unverified claims, score confidence, and fill gaps.
Manage a local knowledge base with kb: search cached results, ingest text/URLs/reports, list/get/delete entries, view stats, and encrypt the store with key management.
Reload configuration live with reload_config: apply config changes without restarting.
Use bundled client skills to turn research into finished writing: research-and-write, fact-check, deep-dive, literature review, competitive evaluation, and gated analysis, with summarization, technical-writing, proofreading, and translation sub-skills.
Customize and extend: add your own skills, bring your own HTTP endpoints as generic providers, and tune fallback, hedging, encryption, and dispatch behavior.
Enables web search via the Brave Search API, supporting higher throughput and specialized queries when an API key is configured.
Provides web search results from DuckDuckGo as a zero-config provider, used in unified search across multiple backends.
Offers access to archived web content through a dedicated renderer, enabling source-specific extraction from the Internet Archive.
Enables web search via a self-hosted SearXNG instance, providing advanced search capabilities when an API key is configured.
Provides search across Wikipedia articles and dedicated content extraction from Wikipedia pages via its specific renderer.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Infobroker search web for recent breakthroughs in fusion energy and verify with multiple sources"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 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.
Related MCP server: MCP Info Gatherer
cd Infobroker && npm install && npm run startAdd this to your OpenCode config (~/.config/opencode/opencode.json):
{
"instructions": [
"<path-to-Infobroker>/instructions/search-preferences.md"
],
"skills": {
"paths": [
"<path-to-Infobroker>/skills",
"<path-to-opencode-config>/skills"
]
},
"mcp": {
"infobroker": {
"type": "local",
"command": ["node_modules/.bin/tsx", "src/index.ts"],
"cwd": "<path-to-Infobroker>",
"environment": {
"INFOBROKER_CONFIG": "<path-to-Infobroker>/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:
export INFOBROKER_BRAVE_API_KEY="your-key"
export INFOBROKER_EXA_API_KEY="your-key"Requirements: Node.js 20+.
Your research backend. Seven tools, twenty-six providers, one corroboration engine. The complete feature inventory is documented in the feature taxonomy in the spec.
"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?"
web_search 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.
"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.
"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.
"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. web_search 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.
"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.
"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 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.
"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. web_search 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.
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.
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:
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.
Variable | Purpose |
| Path to config.json (default: |
| Optional path to a user config layer (default: |
| API key for keyed providers |
| 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.
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:
{
"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=~/.config/infobroker/kb.key
infobroker_manage_kb action=encryption operation=backup key_file=~/.backup/kb.key.bak
infobroker_reload_configAdd 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.
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:
{
"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=<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.
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.
web_search 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.
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.
Tool name | What you're used to | How Infobroker differs |
Built-in | 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-05.
Node.js 20+. node --version. Get it at
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
Providers: DuckDuckGo · Jina Reader · Wikipedia API
Canonical origin: git.gay/flukeatzerocool/Infobroker. This GitHub repository is a read-only mirror.
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.
The server is built from a single source specification, infobroker.md
(v2026.09.05), 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.
Fetch a URL and extract clean content via a renderer (Jina Reader by default, with native-HTTP, Wikipedia, Internet Archive, arXiv, and Stack Exchange renderers). Use when you have a URL and need readable text, want to ask the page a question (question mode returns ranked passages), or need the page's last-updated date (detect_date). Do NOT use for a general topic search (use web_search) or for claim verification across sources (use verify_claims). Makes external HTTP calls, falls back to native HTTP when Jina is throttled, truncates very long pages, and needs no API key. Returns a JSON envelope prefixed [OK] or [ERROR] with status, provider, results, and meta.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to fetch: a single URL, or up to five URLs fetched in parallel | |
| question | No | Question to extract ranked passages for, instead of returning the whole page | |
| renderer | No | Renderer: jina (default), native_fetch, wikipedia, internet_archive, arxiv, or stack_exchange | |
| max_length | No | Maximum characters to return (default 50000) | |
| detect_date | No | Detect and report the page's last-updated date (default from config) | |
| max_passages | No | Number of passages to return (default from config) | |
| passage_size | No | Target words per passage (default from config) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnly, openWorld, and idempotent hints. The description adds meaningful behavioral context beyond that: external HTTP calls, Jina throttling fallback to native HTTP, truncation of long pages, no API key required, and the '[OK]'/'[ERROR]' JSON envelope. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, each earning its place: core function, renderer details, usage/exclusions, behavioral notes. Information is front-loaded with the main purpose, then routed to alternatives, then caveats. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple renderers, question mode, date detection, parallel fetches, fallback behavior, output envelope) and absence of an output schema, the description covers all major behavioral aspects an agent needs to call correctly. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds slight value by clarifying that question mode returns ranked passages and mentioning detect_date, but these are also present in the schema. It does not deeply enrich parameter understanding beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Fetch a URL and extract clean content') and immediately distinguishes itself from siblings by naming web_search and verify_claims as alternatives. An agent can tell exactly what this tool does and what it is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' conditions are given (need readable text, ask a page a question, detect a last-updated date) and explicit 'Do NOT use' exclusions with named alternatives (web_search, verify_claims). This is textbook guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 web_search) or for verifying a contested claim (use verify_claims). Operates without an API key when at least one scholarly source is reachable. Returns a JSON envelope prefixed [OK] or [ERROR].
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| max_results | No | Maximum references to return (1-30, default 8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds meaningful behavioral context: it can operate without an API key under a certain condition and returns a JSON envelope prefixed with [OK] or [ERROR]. It doesn't go into error scenarios or rate limits, but it adds value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: output definition, usage guidance, exclusions with alternatives, and auth/response format. The most important information is front-loaded, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and no output schema, the description covers the return format, citation fields, auth condition, and routing to alternatives. Nothing essential is missing for an agent to decide whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (query, max_results). The description does not add extra parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Return academic references for a query as BibTeX citations with title, authors, year, venue, and URL.' It also explicitly distinguishes itself from sibling tools by excluding general web search and claim verification, so an agent can uniquely identify this tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use ('Use when scholarly writing needs a reference list') and when not to use it, naming alternatives ('use web_search', 'use verify_claims'). Minor deduction because the alternatives are shortened names rather than the exact sibling tool names (infobroker_web_search, infobroker_verify_claims), which could cause an agent to look for a nonexistent tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 web_search) or to read a page (use fetch_page). Read-only: it reports state and never modifies configuration, providers, or stored data. provider is required for the health action; status filters list. Returns a JSON envelope prefixed [OK] or [ERROR] with status, provider, and results.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Operation to perform | |
| status | No | Filter for list action | |
| provider | No | Provider slug (required for health) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description reinforces read-only behavior and states it never modifies configuration, providers, or stored data. It adds useful detail about the JSON envelope prefix ([OK] or [ERROR]) and the meaning of actions, exceeding what annotations alone convey, though it does not discuss authentication or external side effects of a live health check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then flows logically into usage guidance, exclusions, safety, and parameter specifics. Every sentence earns its place, with no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only inspection tool with three well-covered parameters and no output schema, this description is complete. It explains all three actions, the return envelope, conditional parameter requirements, and both positive and negative usage cases. An agent has enough context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already explains each parameter. The description adds meaningful relationships: provider is required for the health action and status filters list. This goes beyond the schema's generic field descriptions by clarifying conditional usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Inspect') and resource ('configured search providers'), then enumerates the concrete actions (list state, live health check, build/spec identity). It explicitly contrasts with sibling tools, naming web_search and fetch_page as the tools this is not, so an agent can distinguish it without inspecting other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use context: when searches return empty or slow results and provider status, quota, or latency matter, or when choosing a trusted backend. It also provides a clear 'Do NOT use' directive with named alternatives, leaving no ambiguity about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage the local knowledge base: search, ingest, list, get, stats, or delete stored content and reports, 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 (list/get), or manage encryption keys. Use the 'encryption' action to enable or disable at-rest encryption, generate or back up a key, verify a key, or re-key the store. Do NOT use for fresh external search (use web_search) or to fetch a new page (use fetch_page). The delete action is destructive and cannot be undone; a lost encryption key makes the store unrecoverable by design. Which parameter each action needs: query for search, text or url for ingest, source_url for get/delete. Returns a JSON envelope prefixed [OK] or [ERROR].
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to fetch and index (for ingest action) | |
| text | No | Raw text to index (for ingest action) | |
| query | No | Search query (for search action) | |
| title | No | Document/report title | |
| action | Yes | Operation to perform | |
| format | No | File format for disk save | markdown |
| save_to | No | Where to save (ingest action): kb, disk, or both. Default kb | |
| key_file | No | Path to a key file (generate_key writes here; rekey reads the target key from here). Never pass the secret itself — only a file path. | |
| operation | No | Sub-operation for the 'encryption' action | |
| collection | No | Collection name | |
| source_url | No | Source URL filter (get/delete action) or identity for ingest | |
| max_results | No | Maximum results to return (1-50, default 8) | |
| source_type | No | Source type (tag on ingest; filter on search/list) | |
| last_updated | No | Source last-updated date to store (e.g. '2026-08-24'); auto-detected from fetched URLs when omitted | |
| freshness_tier | No | Freshness tier tag on ingest (e.g. 'report', 'evergreen') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive behavior, and the description adds crucial specifics: delete cannot be undone, a lost encryption key makes the store unrecoverable by design, and all responses are wrapped in a [OK]/[ERROR] JSON envelope. This goes meaningfully beyond the annotation flags and matches them without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core operation list and every sentence serves a purpose: usage, exclusions, destructive warnings, parameter routing, and output format. It is dense and moderately long, but this is justified given 15 parameters and multiple actions; still, the density requires careful parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity tool with no output schema, the description covers operations, when to use them, forbidden uses, destructive consequences, encryption specifics, parameter mapping, and the response envelope. It does not specify the exact response shape for list/stats/get, and the source_url/url naming inconsistency remains a small gap. Overall, quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds useful action-to-parameter routing (query for search, text for ingest, source_url for get/delete) and report-ingest guidance, but it also references a 'url' parameter for ingest that does not actually exist in the schema—ingest URLs are handled by source_url. This minor inaccuracy undercuts the added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with a specific verb ('Manage') and a clear resource ('local knowledge base'), then enumerates the exact operations: search, ingest, list, get, stats, delete, and encryption. It distinguishes itself from external-tool siblings by explicitly scoping to 'local' content and later naming web_search and fetch_page as the external alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when...' guidance for archiving reports, revisiting stored content, and managing encryption keys. It also gives a clear 'Do NOT use for...' exclusion with named sibling tools (web_search and fetch_page), so an agent knows when to route elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 and want the changes applied immediately. Do NOT use to inspect configuration or provider state (use inspect_providers). If the new configuration is invalid, the previous configuration stays active and an error is returned. Returns a JSON envelope prefixed [OK] or [ERROR].
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors beyond annotations: active connections are preserved, an invalid new configuration leaves the previous one active and returns an error, and the response is a JSON envelope prefixed with [OK] or [ERROR]. These are all useful operational details that the empty schema and annotations do not capture. There is no contradiction with readOnlyHint=false or idempotentHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four focused sentences: main function and effect, when to use, when not to use with alternative, and failure behavior/return format. Every sentence carries distinct, valuable guidance, and the most important operational facts are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no input parameters and no output schema, the description is complete: it explains what the tool does, when to invoke it, the alternative, the failure safety, and the response envelope format. An agent has everything needed to call and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are trivially complete; the schema already covers everything with an empty properties object. The description adds no parameter-specific detail because none is needed. This aligns with the 0-parameter baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Re-read') and resource ('configuration file') and clearly states what changes are applied (provider, rate-limit, knowledge-base) without restarting. It also explicitly distinguishes itself from the sibling inspect_providers by saying what it is NOT for, so an agent can select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states precisely when to use the tool ('when you have edited config.json or config.local.json and want the changes applied immediately') and when not to use it ('Do NOT use to inspect configuration or provider state'), naming the alternative inspect_providers. This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a multi-pass truth-finding loop that searches across providers, reconciles claims across independent sources, and returns confidence-scored findings with per-claim source attribution. 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 web_search) or for citation formatting (use get_citations). Makes multiple searches bounded by max_iterations and per-provider rate limits, recalls prior findings from the knowledge base, and indexes its findings back into the knowledge base. max_iterations bounds the refinement passes; confidence_threshold is the bar for a finding to be reported confirmed. Returns a JSON envelope prefixed [OK] or [ERROR].
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| priority | No | Route the corroboration pool by intent | |
| providers | No | Optional array of provider slugs to limit the search to | |
| max_iterations | No | Maximum search-refinement passes (1-10, default 5) | |
| confidence_threshold | No | Minimum confidence to report a finding as confirmed (0-1, default 0.8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the sparse annotations: it discloses multiple searches bounded by max_iterations, provider rate limits, knowledge base recall and indexing side effects, and the [OK]/[ERROR] envelope. This meaningfully informs an agent about cost, non-idempotence, and side effects, and does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but mostly purposeful, front-loading the core function and return value before usage guidance and limits. A minor redundancy exists between 'multi-pass' and 'Makes multiple searches,' but overall every sentence contributes meaningful decision or behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description covers return format, confidence scoring, source attribution, side effects, and failure prefixing. For a complex, multi-call tool with no structured output definition, this is sufficient for an agent to understand what it will receive and what the tool will do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds interpretive context for max_iterations and confidence_threshold, but does not add meaning beyond the schema for query, priority, or providers. This is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a rich, specific operation: a multi-pass truth-finding loop that searches providers, reconciles claims, and returns confidence-scored, source-attributed findings. This clearly distinguishes it from simpler sibling search or citation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (high-stakes or contested claims needing agreement, contradiction, gaps) and when not to use simple lookups or citation formatting, naming web_search and get_citations as alternatives. This is ideal routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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), or ranked passages from the top pages (deep). Do NOT use for a URL you already have (use fetch_page), for high-stakes claim verification (use verify_claims), for stored-report recall (use manage_kb search), or for academic citations (use get_citations). Caches results in the local knowledge base, enforces per-provider rate limits, and needs no API key for the free providers. Returns a JSON envelope prefixed [OK] or [ERROR] with status, provider, results, and meta.
| Name | Required | Description | Default |
|---|---|---|---|
| deep | No | Read the top results and return each page's ranked passages against the query | |
| page | No | Results page number (default 1) | |
| query | Yes | Search query: a single string, or up to five strings searched in parallel | |
| expand | No | Return query-expansion strings instead of search results | |
| region | No | ISO region/country code (e.g. 'us-en', 'DE') | |
| suggest | No | Return query-autocomplete strings instead of results (default false) | |
| priority | No | Route by intent: speed, quality, privacy, or free_only | |
| provider | No | Provider slug (auto-select if omitted) | |
| time_range | No | Restrict results to day, week, month, or year | |
| max_results | No | Number of results to return (1-30, default 8) | |
| safe_search | No | Safe-search filtering: on, off, or strict (default on) | on |
| content_type | No | Source kind to search: docs, issue, changelog, blog, spec, or all (default all) | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the readOnly/openWorld/idempotent annotations by disclosing automatic provider selection, fallback chain, local caching, per-provider rate limits, no API key requirement, and the [OK]/[ERROR] JSON envelope. These details accurately describe observable behavior without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core function, then gives usage conditions, alternatives, behavioral notes, and return format in a compact paragraph. Every sentence contributes distinct information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, the description covers return envelope, modes, cachiing, rate limits, authentication, and sibling routing. The completeness is high enough for an agent to select and invoke the tool correctly without opening the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 100%, the description adds semantic meaning beyond the schema by mapping modes to parameters: batched search for query arrays, suggest for autocomplete, expand for query expansion, and deep for ranked passages. It also connects automatic provider selection to provider/priority routing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific action and resource: search web, encyclopedia, academic, and code sources through one interface. It further differentiates from siblings by explicitly naming what it is not for (URLs, high-stakes verification, stored reports, academic citations), making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit positive conditions ('Use when you need broad or batched search...') and explicit exclusions with named alternatives ('Do NOT use for a URL... use fetch_page'). This gives an agent clear decisional criteria for routing to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1infobroker_corroborateinfobroker_fetch_page9 fields changedInput schema / properties / detect_dateAdded value: +{
+ "description": "Detect and report the page's last-updated date (default from config)",
+ "type": "boolean"
+}Input schema / properties / max_length / descriptionAdded value: +"Maximum characters to return (default 50000)"Input schema / properties / max_passagesAdded value: +{
+ "description": "Number of passages to return (default from config)",
+ "type": "number"
+}Input schema / properties / passage_sizeAdded value: +{
+ "description": "Target words per passage (default from config)",
+ "type": "number"
+}Input schema / properties / questionAdded value: +{
+ "description": "Question to extract ranked passages for, instead of returning the whole page",
+ "type": "string"
+}Input schema / properties / renderer / descriptionAdded value: +"Renderer: jina (default), native_fetch, wikipedia, internet_archive, arxiv, or stack_exchange"Input schema / properties / url / anyOfAdded value: +[
+ {
+ "description": "URL to fetch",
+ "type": "string"
+ },
+ {
+ "description": "Multiple URLs to fetch in parallel (max 5)",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 5,
+ "type": "array"
+ }
+]Input schema / properties / url / descriptionPrevious value: -"URL to fetch"New value: +"URL to fetch: a single URL, or up to five URLs fetched in parallel"Input schema / properties / url / typeRemoved value: -"string"infobroker_get_citationsinfobroker_inspect_providersinfobroker_kbinfobroker_manage_kbinfobroker_providersinfobroker_verify_claimsinfobroker_web_search12 fields changedInput schema / properties / content_type / descriptionAdded value: +"Source kind to search: docs, issue, changelog, blog, spec, or all (default all)"Input schema / properties / deepAdded value: +{
+ "default": false,
+ "description": "Read the top results and return each page's ranked passages against the query",
+ "type": "boolean"
+}Input schema / properties / expandAdded value: +{
+ "default": false,
+ "description": "Return query-expansion strings instead of search results",
+ "type": "boolean"
+}Input schema / properties / max_results / descriptionAdded value: +"Number of results to return (1-30, default 8)"Input schema / properties / page / descriptionAdded value: +"Results page number (default 1)"Input schema / properties / priority / descriptionAdded value: +"Route by intent: speed, quality, privacy, or free_only"Input schema / properties / query / anyOfAdded value: +[
+ {
+ "description": "Search query",
+ "type": "string"
+ },
+ {
+ "description": "Multiple queries to search in parallel (max 5)",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 5,
+ "type": "array"
+ }
+]Input schema / properties / query / descriptionPrevious value: -"Search query"New value: +"Search query: a single string, or up to five strings searched in parallel"Input schema / properties / query / typeRemoved value: -"string"Input schema / properties / safe_search / descriptionAdded value: +"Safe-search filtering: on, off, or strict (default on)"Input schema / properties / suggest / descriptionAdded value: +"Return query-autocomplete strings instead of results (default false)"Input schema / properties / time_range / descriptionAdded value: +"Restrict results to day, week, month, or year"v0.1.0infobroker_corroborateinfobroker_fetch_pageinfobroker_kbinfobroker_providersinfobroker_reload_configinfobroker_web_searchEach tool has a clearly distinct role: search, fetch URL, citations, claim verification, KB management, provider inspection, and config reload. Cross-references explicitly steer agents away from overlapping uses (e.g., web_search vs verify_claims).
All tools share the infobroker_ prefix and use lowercase snake_case, and most follow a verb_object pattern (get_citations, fetch_page, manage_kb, reload_config). web_search is the one minor deviation from that pattern, but still fits the overall naming style.
Seven tools is well-scoped for an information-brokering server: core search/fetch/verify/citation operations plus supporting KB, provider, and config tools. Each tool earns its place without redundancy.
The surface covers the full research workflow: broad search, targeted page fetching, citation generation, high-stakes verification, and local KB storage/retrieval. Supporting operations for provider health and live config reload prevent operational dead ends.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/flukeatzerocool/infobroker'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
