Bintu Web Context

Bintu Scrape Text

bintu_scrape_text

Read-onlyIdempotent

Fetch a public webpage and extract its readable article or main text, removing page clutter. Return clean text, chunked content, or sentence summaries for AI-agent context.

Instructions

Fetch one public absolute HTTP or HTTPS URL and extract readable text. Only HTML/XHTML is supported, with a 1 MiB decoded-body limit and extracted text capped at 6,000 characters. Article/main content is preferred and common page furniture is omitted. Default mode=scrape returns the extraction envelope. Use mode=chunk (accepted alias: chunked) for approximately budgeted chunks, or mode=summarize for sentence-based truncation. Chunking preserves words, URLs, and recognized table rows; an intact URL, word, or table row may exceed max_tokens. Whitespace can be normalized during chunking. tokens and approx_tokens are character-based sizing estimates, not tokenizer counts or exact billing measurements. tokens_saved_estimate compares source HTML and delivered text estimates when the baseline is available; cached results may preserve the original extraction economics. Savings are not limited to summarize mode. truncated reports content truncation; split reports multiple chunks. The character cap applies before mode transformation. max_tokens is ignored in scrape mode. Set cache=false to bypass cache reads; successful fresh results may still be written to cache. JavaScript rendering is available only when enabled by the operator. If render_js_disabled is returned, retry with render_js=false. Execution failures are reported in-band with isError=true.

Input Schema

Name	Required	Description	Default
`url`	Yes	Absolute public HTTP or HTTPS URL to extract. Unsafe targets fail with invalid_or_unsafe_url.
`mode`	No	scrape returns extracted text in the envelope; chunk creates approximately budgeted chunks; summarize selects leading sentences within an approximate budget. The accepted chunked alias normalizes to chunk.	scrape
`cache`	No	Read available memory/persistent caches. False bypasses cache reads but does not disable writes of fresh results.
`persist`	No	Allow a fresh successful result to be written to the persistent cache. False prevents that write; memory caching and extraction are unchanged.
`render_js`	No	Render in Chromium before extraction when enabled by the operator. If render_js_disabled is returned, retry with false.
`max_tokens`	No	Approximate token budget for chunk/summarize modes; ignored in scrape mode. Accepted alias: chunk_token_budget. The extracted-text character cap applies first. Indivisible units in chunk mode, and a first oversized sentence in summarize mode, may exceed the budget.

Output Schema

Name	Required	Description
`mode`	Yes
`split`	Yes
`chunks`	Yes
`tokens`	Yes	Compatibility alias of approx_tokens.
`cache_hit`	Yes
`truncated`	Yes
`source_url`	Yes
`cache_layer`	Yes
`chunk_count`	Yes
`html_tokens`	Yes
`extracted_at`	Yes
`token_method`	Yes
`approx_tokens`	Yes
`limiting_factor`	Yes
`tokens_saved_estimate`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.1Oct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, but the description goes well beyond them: 1 MiB decoded-body limit, 6,000-character cap applied before mode transformation, cache read vs. write asymmetry, operator-gated JavaScript rendering, and in-band error reporting with isError=true. It also warns that tokens/approx_tokens are character-based estimates, not tokenizer counts, which prevents misinterpretation of results.

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 and constraints are front-loaded, and nearly every sentence carries operational information. A few sentences, notably the tokens_saved_estimate line about 'original extraction economics,' are dense and slightly jargon-heavy relative to the value they add.

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

Completeness5/5

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

With an output schema present, the description need not explain return payloads, yet it still names key signals (truncated, split, cached results, isError) so the agent knows what to inspect. Limits, mode transform order, cache behavior, and JS fallback are all covered for a 6-parameter tool.

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 the baseline is 3; the description earns extra credit by clarifying that the character cap applies before mode transformation, that chunking preserves whole words/URLs/table rows (which may exceed max_tokens), and that cache=false does not disable writes. A little of this overlaps the schema's own max_tokens description, keeping it just short of 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?

Opens with a specific verb and resource: 'Fetch one public absolute HTTP or HTTPS URL and extract readable text.' It immediately scopes the tool to HTML/XHTML, single URL, with explicit size limits, so there is no ambiguity about what it does or returns.

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 explicit mode-selection guidance (default scrape vs. chunk vs. summarize) plus conditional operating rules: set cache=false to bypass reads, retry with render_js=false if render_js_disabled is returned, and note that max_tokens is ignored in scrape mode. These are concrete when-to/when-not instructions an agent can act on without trial and error.

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

Deploy Server

Other Tools

bintu_scrape_textA