Infobroker

Fetch Page Content

infobroker_fetch_page

Idempotent

Fetch a URL and extract clean content via a renderer (Jina Reader by default; native-HTTP, Wikipedia, Internet Archive, arXiv, and Stack Exchange alternatives).

Instructions

Fetch a URL and extract clean content via a renderer (Jina Reader by default; native-HTTP, Wikipedia, Internet Archive, arXiv, and Stack Exchange alternatives). Use when you have a URL and need readable text, passages ranked against a question, or the page's last-updated date. Do NOT use for topic search (use infobroker_search_web) or cross-source claim verification (use infobroker_verify_claims). question returns passages ranked against it, sized by passage_size and capped by max_passages; crawl bounds the same-origin crawl to config caps; extract adds JSON-LD, OpenGraph, and microdata; renderer selects the backend, and native_fetch is the keyless fallback when Jina is throttled or anti-bot challenged. max_length truncates the returned text only; a truncated page is written in full to a temp file. Makes external HTTP calls and needs no API key. A fresh knowledge-base copy is returned before an outbound fetch when available. Fetched pages auto-index into the knowledge base unless the content policy flags them (see infobroker_manage_kb): flag mode returns without storage, block mode refuses. Unreachable URLs return an [ERROR] envelope with remediation; success returns an [OK] envelope with status, provider, results, and meta.

Input Schema

Name	Required	Description
`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)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.2Sep 9, 2026

addedInput schema / properties / crawl

Added value: +{
+  "default": false,
+  "description": "Bounded same-origin crawl: recursively fetch same-origin pages up to config caps (default off)",
+  "type": "boolean"
+}

addedInput schema / properties / extract

Added value: +{
+  "default": false,
+  "description": "Return structured metadata (JSON-LD, OpenGraph, microdata) alongside the content (default off)",
+  "type": "boolean"
+}

Changed9 schema fields changedv0.1.1Sep 2, 2026

addedInput schema / properties / detect_date

Added value: +{
+  "description": "Detect and report the page's last-updated date (default from config)",
+  "type": "boolean"
+}

addedInput schema / properties / max_length / description

Added value: +"Maximum characters to return (default 50000)"

addedInput schema / properties / max_passages

Added value: +{
+  "description": "Number of passages to return (default from config)",
+  "type": "number"
+}

addedInput schema / properties / passage_size

Added value: +{
+  "description": "Target words per passage (default from config)",
+  "type": "number"
+}

addedInput schema / properties / question

Added value: +{
+  "description": "Question to extract ranked passages for, instead of returning the whole page",
+  "type": "string"
+}

addedInput schema / properties / renderer / description

Added value: +"Renderer: jina (default), native_fetch, wikipedia, internet_archive, arxiv, or stack_exchange"

addedInput schema / properties / url / anyOf

Added value: +[
+  {
+    "description": "URL to fetch",
+    "type": "string"
+  },
+  {
+    "description": "Multiple URLs to fetch in parallel (max 5)",
+    "items": {
+      "type": "string"
+    },
+    "maxItems": 5,
+    "type": "array"
+  }
+]

changedInput schema / properties / url / description

Previous value: -"URL to fetch"New value: +"URL to fetch: a single URL, or up to five URLs fetched in parallel"

removedInput schema / properties / url / type
```
Removed value: -"string"
```

First observedv0.1.0Aug 25, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, openWorldHint=true, idempotent=true, destructive=false, but the description adds substantial context beyond them: external HTTP calls, no API key needed, knowledge-base cache returned before an outbound fetch, auto-indexing with content-policy flag/block behavior, and [OK]/[ERROR] envelopes with remediation. The only minor gap is it doesn't caveat that 'idempotent' can be undermined by live page changes, and the content-policy details are deferred to infobroker_manage_kb.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, followed by usage routing, then parameter behavior, then behavioral caveats. It is dense and backtick-heavy, packing many clauses per sentence, but nearly every sentence carries distinct information; slight tightening would improve readability without losing content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, no-output-schema, network-touching tool, the description covers the important gaps: return envelopes, error handling, caching, and KB side effects. It relies on a pointer to infobroker_manage_kb for policy details rather than explaining them, and the shape of 'results' and 'meta' within the [OK] envelope is left implicit, which keeps it one step shy of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds genuine value: the interaction between question/passage_size/max_passages, the crawl config caps, what extract returns, and the operational reason to pick native_fetch (keyless fallback when Jina is throttled or anti-bot challenged). It also clarifies that max_length truncates only the returned text and that the full page is written to a temp file. It omits any mention of detect_date, which keeps it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Fetch a URL and extract clean content') plus the renderer backends, and explicitly distinguishes itself from infobroker_search_web and infobroker_verify_claims. An agent can identify this as the single-URL content retrieval tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit use condition ('when you have a URL and need readable text, passages ranked against a question, or the page's last-updated date') and explicitly names two anti-cases with the sibling tools to use instead. This is the when/when-not/alternative pattern at full strength.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Fetch Page Content

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools