Infobroker is a multi-provider MCP research server that unifies search, extraction, verification, knowledge management, citation, and writing workflows behind one tool surface.
Unified search — search the web, academic, encyclopedia, news, and code sources through one interface with automatic provider selection, fallback chains, batched queries, deep passage ranking, research compiles, autocomplete, query expansion, and intent-based routing.
Content extraction — fetch any URL and get clean Markdown via pluggable renderers (Jina, native HTTP, Wikipedia, Internet Archive, arXiv, Stack Exchange), ask a page a question for ranked passages, detect last-updated dates, extract structured metadata, or run bounded same-origin crawls.
Claim verification — run a multi-pass truth-finding loop that reconciles claims across independent sources, surfaces agreement/contradiction/gaps, and returns confidence-scored findings with source provenance.
Knowledge base — search, ingest (text, URLs, reports), list, get, delete, and stat cached content; encrypt the store at rest; archive reports for later recall; retrieval runs locally.
Citations — get BibTeX references for scholarly topics with title, authors, year, venue, and URL.
Operational visibility — inspect provider status, run live health checks, view build/spec identity, and see quota/latency per backend.
Hot configuration — reload config changes without restarting, including providers, rate limits, and knowledge-base settings.
Bundled writing skills — orchestrate the tools into research-and-write, fact-check, deep-dive, literature review, monitoring, and gated-analysis workflows with summarization, technical-writing, proofreading, and translation sub-skills.
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 "Deploy 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?"
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.
"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. 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.
"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. 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 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. 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.
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.
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.
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, 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.
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.
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=~/.local/share/infobroker/keys/kb.key
infobroker_manage_kb action=encryption operation=backup key_file=~/.local/share/infobroker/keys/kb.key.bak
infobroker_reload_configTool-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.
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.
{
"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).
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.
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.
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-14.
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.14), 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, need the page's last-updated date (detect_date), a bounded same-origin crawl (crawl), or structured metadata (extract). Do NOT use for a general topic search (use infobroker_search_web) or for claim verification across sources (use infobroker_verify_claims). Parameter interactions: question switches the response from the whole page to passages ranked against it, sized by passage_size and capped by max_passages; crawl recursively fetches same-origin pages up to config caps; max_length caps the characters returned (default 50000); extract adds JSON-LD, OpenGraph, and microdata alongside the content; renderer selects the extraction backend — jina needs no API key and native_fetch is the fallback when Jina is throttled. Makes external HTTP calls, truncates very long pages, and needs no API key. Fetched pages are auto-indexed into the knowledge base unless the content policy flags them (see manage_kb), in which case flag mode returns them without storage and block mode refuses them. 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 | |
| crawl | No | Bounded same-origin crawl: recursively fetch same-origin pages up to config caps (default off) | |
| extract | No | Return structured metadata (JSON-LD, OpenGraph, microdata) alongside the content (default off) | |
| 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?
The description transparently mentions external HTTP calls, truncation, no API key, auto-indexing into the knowledge base, and flag/block modes. However, it contradicts the readOnlyHint annotation by saying fetched pages are auto-indexed into the knowledge base, which is a state-modifying side effect.
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 and information-rich, but it is long and somewhat run-on. Every sentence adds useful detail, so it remains efficient overall, though tighter phrasing would improve scannability.
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?
Covers output envelope format ([OK]/[ERROR] with status, provider, results, meta), side effects, and distinctions from siblings. With no output schema, a slightly more detailed error/edge-case description would make it fully complete, but the essential context is present.
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%, and the description adds meaningful parameter interactions: question switches output to ranked passages, crawl is a bounded same-origin crawl, max_length caps characters, renderer selects backend, and passage_size/max_passages control passage output. This goes well beyond the basic schema.
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?
States a specific action (fetch a URL and extract clean content) and clearly distinguishes this tool from siblings like search_web and verify_claims. The resource and the main task are 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?
Explicitly tells when to use the tool (have a URL, need readable text, ask page-specific questions, detect dates, crawl, extract metadata) and when not to use it (general search, cross-source verification), routing to the correct sibling tools.
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 infobroker_search_web) or for verifying a contested claim (use infobroker_verify_claims). Operates without an API key when at least one scholarly source is reachable; when every scholarly source is unreachable it returns an [ERROR] envelope with remediation, and queries respect each provider's rate limits. Parameter semantics: query should name the topic in natural language; max_results bounds the reference list (1–30, default 8) — larger values take longer and span more sources. 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?
The description adds meaningful behavioral detail beyond the readOnly/idempotent annotations: it explains operation without an API key, failure behavior when all sources are unreachable (returning an [ERROR] envelope with remediation), and respect for provider rate limits. No contradiction with the annotations exists.
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 well-organized and front-loads the core purpose and usage. Some redundancy exists with the schema parameter descriptions, but the added context (rate limits, error envelope, output format) justifies the length.
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?
With no output schema, the description sufficiently covers the return format (BibTeX citation fields and JSON envelope with [OK]/[ERROR] prefixes), error behavior, rate-limit handling, and parameter semantics. This is complete for an agent to invoke and interpret the result 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 schema already describes both parameters, and the description reinforces them with practical semantics: query should be natural language, max_results bounds the list, and larger values take longer and span more sources. This adds useful guidance without conflicting with the schema.
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 clearly states that the tool returns academic references as BibTeX citations with title, authors, year, venue, and URL. It also specifies the intended use case (scholarly writing needing a reference list) and distinguishes it from sibling 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?
Explicit when-to-use guidance is provided, along with direct when-not-to-use instructions that name the correct alternatives (infobroker_search_web for general web search, infobroker_verify_claims for contested claims). This leaves no ambiguity about selecting this 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 infobroker_search_web) or to read a page (use infobroker_fetch_page). Read-only: it reports state and never modifies configuration, providers, or stored data. Action semantics: list snapshots provider state locally; health runs a live outbound probe against the provider named in provider (external calls subject to that provider's rate limits and availability, so it can be slow); spec reports build and spec identity locally. status only filters list; provider is required for the health action. 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?
Beyond the readOnly and idempotent annotations, the description explicitly states that the tool never modifies configuration, providers, or stored data. It also discloses that the health action performs a live outbound probe subject to rate limits and availability, which is important behavioral context not captured by the annotations alone.
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 well-structured and concise despite covering multiple actions and caveats. It front-loads the core purpose, then gives usage guidance, action semantics, and return format without unnecessary repetition 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?
Given the moderate complexity of three actions and conditional parameters, the description is complete. It explains return format ([OK] or [ERROR] envelope), the role of each action, and how the parameters interact, providing enough context for an agent to invoke the tool correctly without an output 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?
The schema descriptions are complete, and the tool description adds essential semantics: it explains what each action does, that 'status' only filters the 'list' action, and that 'provider' is required for 'health' despite being optional in the schema. This significantly enriches the bare parameter descriptions.
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 clearly states the tool's purpose as inspecting configured search providers via three explicit actions (list, health, spec), and explains when to use it (for provider status, quota, latency, or choosing a backend). It also explicitly differentiates it from search and fetch tools, leaving no ambiguity about its scope.
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 provides concrete usage guidance, including when to use the tool ('when searches return empty or slow results') and when not to use it, naming the alternative tools (infobroker_search_web and infobroker_fetch_page). It also explains the semantics of each action, making the intended use clear.
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 cached content, ingest text or URLs, list/get/delete entries, view stats, 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: action selects the operation; query for search, text or url for ingest, source_url for get/delete, operation with key_file for the encryption sub-actions; save_to defaults to 'kb', format to 'markdown', max_results to 8; last_updated is auto-detected from fetched URLs when omitted. Responses carry an [OK] or [ERROR] JSON envelope: search/list/get return matching entries, stats returns counts, and delete reports the chunks removed.
| 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?
The description goes beyond the destructiveHint annotation by explicitly warning that delete is destructive and cannot be undone, and that a lost encryption key makes the store unrecoverable. It also discloses that ingest can save to kb/disk/both and that encryption operations generate or rekey keys, making side effects clear.
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 well organized: it opens with the core purpose, lists operations, gives usage direction, states destructive consequences, and summarizes parameter/response behavior in a compact set of sentences. Each sentence contributes distinct information without 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?
Despite having no output schema, the description specifies the response envelope as [OK] or [ERROR] and details what each action returns: search/list/get return entries, stats returns counts, and delete reports chunks removed. It also covers important behavioral context like key file handling and default behaviors, making the tool fully actionable.
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?
Although the schema already has 100% parameter description coverage, the tool description adds valuable cross-parameter semantics: it maps each action to its relevant parameters, explains that save_to defaults to 'kb' and max_results to 8, notes that last_updated is auto-detected from fetched URLs, and warns that key_file must only be a path, never the secret itself.
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 clearly states the tool manages the local knowledge base and enumerates specific operations: search, ingest, list, get, delete, stats, and encryption. It explicitly contrasts with sibling tools by saying do NOT use for fresh external search or fetching a new page, naming infobroker_search_web and infobroker_fetch_page.
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 gives explicit when-to-use guidance: archive a generated report with source_type 'report' and save_to 'kb', revisit stored content, or manage encryption keys. It also explicitly states when not to use the tool and points to the appropriate sibling tools, leaving no ambiguity about selection.
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 infobroker_inspect_providers). The tool takes no arguments: the configuration source is fixed at startup (INFOBROKER_CONFIG, merged with config.local.json), and this call simply re-reads it from disk. 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 discloses key behaviors beyond the annotations: no restart required, active connections preserved, and rollback to previous config on invalid input. This gives the agent a clear model of side effects and safety.
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 well-organized, covering purpose, usage, behavior, and output in three sentences without redundancy. Every sentence adds value.
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 zero-parameter tool, the description provides all necessary context: what it does, when to invoke it, what side effects occur, and what output format to expect. No gaps remain.
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; the description explicitly notes 'takes no arguments', which is accurate and complete. Schema coverage is trivially 100%, and no additional parameter explanation is needed.
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 clearly states the tool's function with a specific verb ('re-read', 'apply') and resource ('configuration'), and distinguishes it from the sibling inspection tool by naming the alternative (infobroker_inspect_providers). No ambiguity.
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 (after editing config files) and when not to use (for inspection, pointing to the correct tool). Provides direct, actionable 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), ranked passages from the top pages (deep), or a multi-variant research compile that deep-reads each variant (research). 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. 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) | |
| research | No | Research compile: fan out to derived query variants and deep-read each, returning passages grouped by variant (default off) | |
| 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?
Discloses caching, rate-limit enforcement, no-API-key behavior, and the [OK]/[ERROR] JSON envelope. These details align with the readOnlyHint, openWorldHint, idempotentHint, and destructiveHint 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 compact but information-dense, using clear 'Use when' and 'Do NOT use' sections without redundant 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?
Even without an output schema, it names the return envelope and its top-level fields, describes side effects, and gives enough context for an agent to choose 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?
All 13 parameters are described, with defaults and enums explicitly covered; the query parameter's string-or-array(max 5) behavior is explained, and mode flags like deep/expand/suggest/research are clarified.
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?
States the tool searches web, encyclopedia, academic, and code sources through one interface, with a clear 'Use when...' list covering broad/batched search and modes. It also names sibling tools for disambiguation.
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 describes when to use it and when not to, pointing to infobroker_fetch_page, verify_claims, manage_kb, and get_citations for exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a 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 infobroker_search_web) or for citation formatting (use infobroker_get_citations). max_iterations bounds the search-refinement passes and per-provider rate limits apply; the loop recalls prior findings from the knowledge base and indexes its findings back into it. Parameter semantics: query should state the claim plainly rather than as a question; priority routes the corroboration pool by intent (speed, quality, privacy, free_only); providers restricts the pool to the given slugs, and omitting it uses the full dispatch chain; 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 discloses that the tool runs a loop, searches providers, reconciles claims, and 'indexes its findings back into' the knowledge base, implying a write side-effect. It also mentions per-provider rate limits. However, it does not explicitly state that it may modify the KB or mention any potential costs, leaving some ambiguity about the exact mutation behavior.
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 highly redundant, repeating the same concepts multiple times (e.g., 'truth-finding loop', 'confidence-scored findings', 'indexes its findings'). It could be condensed to a few sentences without losing any information. The structure is a dense block, making it harder to parse quickly.
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 lack of an output schema, the description adequately covers what the tool does, how it behaves (including side effects), and how to configure key parameters. It also provides context on when to use it and mentions constraints like rate limits and iteration bounds. Minor gaps remain, such as not specifying the exact response structure beyond a 'JSON envelope'.
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 schema already covers all five parameters, so the description adds limited new detail. It does clarify that 'query' should be a plain claim rather than a question and that 'priority' routes by intent, which slightly enriches the schema's descriptions. Overall, the schema does the heavy lifting, but the additions provide modest extra guidance.
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 clearly states the tool's purpose: runs a truth-finding loop to reconcile claims across multiple providers and returns confidence-scored findings with attribution. It also specifies when to use it (high-stakes or contested claims) and explicitly distinguishes it from sibling tools like search_web and get_citations.
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 provides explicit guidance on when not to use the tool (simple lookups, broad search, citation formatting) by naming alternative tools. It also gives a concrete use case (high-stakes/contested claims) and explains key behaviors like bounding iterations and applying confidence thresholds.
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.
v0.1.2infobroker_fetch_page2 fields changedInput schema / properties / crawlAdded value: +{
+ "default": false,
+ "description": "Bounded same-origin crawl: recursively fetch same-origin pages up to config caps (default off)",
+ "type": "boolean"
+}Input schema / properties / extractAdded value: +{
+ "default": false,
+ "description": "Return structured metadata (JSON-LD, OpenGraph, microdata) alongside the content (default off)",
+ "type": "boolean"
+}infobroker_search_webinfobroker_web_searchv0.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_searchScored across 7 tools
Each tool targets a distinct operation, and the descriptions explicitly cross-reference neighboring tools to prevent confusion. Search, page fetching, claim verification, citation retrieval, KB management, provider inspection, and config reload are sharply separated by intent and use case.
All tools follow the uniform infobroker_ prefix with verb_noun snake_case naming: search_web, fetch_page, inspect_providers, verify_claims, manage_kb, reload_config, and get_citations. The pattern is completely consistent and predictable.
Seven tools is a well-scoped count for an integrated research and information platform. Each tool covers a distinct capability without redundancy, and there is no sense of bloat or thinness.
The tool set covers the full workflow: broad search, targeted page fetching, claim verification, citation generation, knowledge base management, provider health inspection, and configuration reloading. There are no obvious dead ends or missing core operations for the stated purpose.
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.
