Infobroker

Fetch Page Content

infobroker_fetch_page

Read-onlyIdempotent

Fetch a URL and extract clean content using multiple renderers. Supports targeted questions, recursive crawling, metadata extraction, and content length control.

Instructions

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.

Input Schema

TableJSON 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.0

Behavior1/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Fetch Page Content

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools