Skip to main content
Glama

Fetch page as clean text

fetch_extract
Read-only

Fetches a public HTTP(S) URL and returns cleaned plain text with scripts, styles, navigation, and boilerplate removed, reducing token use for AI agents.

Instructions

Free, read-only. Fetch a public http(s) URL and return its body as plain text: script, style, nav, header, footer and aside removed, tags stripped, entities decoded, whitespace collapsed. Median 98% fewer tokens than raw HTML. Follows up to 5 redirects, 10 s timeout; private and local hosts are rejected and non-2xx responses error with the HTTP status. Text past maxChars is cut and ends with '[Truncated at N chars]': raise maxChars (max 32000) or use fetch_html for everything. Runs no JavaScript: a client-side-rendered SPA or a bot/login wall yields almost no text, so the call errors instead of returning an empty shell and names the fix (fetch_rendered, paid, runs a browser; screenshot_url; or headers for auth). For title/OG/JSON-LD only use fetch_metadata; for Markdown with links use html_to_markdown.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "fetch_extract"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesPublic http:// or https:// URL. Local and private hosts are rejected.
headersNoHeaders to forward for pages behind login: Authorization, Cookie, X-API-Key only. Dropped if a redirect leaves the original host.
maxCharsNoCharacters of text to return. Default 8000, max 32000 (higher values are clamped). Truncated output ends with a '[Truncated at N chars]' marker.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.6
    • changedInput schema / properties / headers / description
      Previous value: -"Headers to forward (Authorization, Cookie…)."New value: +"Headers to forward for pages behind login: Authorization, Cookie, X-API-Key only. Dropped if a redirect leaves the original host."
    • changedInput schema / properties / maxChars / description
      Previous value: -"Default 8000, max 32000."New value: +"Characters of text to return. Default 8000, max 32000 (higher values are clamped). Truncated output ends with a '[Truncated at N chars]' marker."
    • changedInput schema / properties / url / description
      Previous value: -"Page URL."New value: +"Public http:// or https:// URL. Local and private hosts are rejected."
  2. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / headers
      Added value: +{
      +  "description": "Headers to forward (Authorization, Cookie…).",
      +  "type": "object"
      +}
    • changedInput schema / properties / maxChars / description
      Previous value: -"Max characters to return (default 8000, max 32000)"New value: +"Default 8000, max 32000."
    • changedInput schema / properties / url / description
      Previous value: -"The URL to fetch and extract text from"New value: +"Page URL."
  3. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses extensive behavior beyond the readOnlyHint annotation: redirect limits, timeout, private-host rejection, non-2xx error behavior, truncation, absence of JavaScript execution, and the failure mode for SPAs or bot walls. It also explains the fix path for those failures, which is unusually helpful for an agent.

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

Conciseness5/5

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

The description is dense but well structured and front-loaded: purpose first, then processing behavior, limits, failure modes, and alternatives. Every sentence carries actionable information, and the length is justified by the tool's complexity.

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 no output schema and only a readOnlyHint annotation, the description carries the full burden and does so thoroughly. It explains the return format, truncation marker, error behavior, and the key limitations an agent must know before invoking the tool.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters are already documented in the input schema. The description reinforces the maxChars truncation behavior and mentions headers for authentication, but it does not add much parameter semantics beyond what the schema already states.

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 public HTTP(S) URL and return its body as plain text. It also carefully distinguishes the output from siblings by naming fetch_html, fetch_metadata, html_to_markdown, and fetch_rendered with their respective use cases.

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 covers when to use this tool, when not to use it, and which alternatives to choose. It names the conditions that select fetch_html, fetch_metadata, html_to_markdown, fetch_rendered, screenshot_url, and authenticated headers.

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