Skip to main content
Glama

fetch_reader

Read-onlyIdempotent

Fetch a URL and extract the main article as clean markdown, stripping headers, footers, and sidebars to provide focused content for LLM processing.

Instructions

GET a URL, locate the main article body (prefers , , itemprop=articleBody, or known CMS class names; falls back to ), strip navigation/footer/aside chrome, and convert to clean markdown. Returns { title, byline, markdown, wordCount }. Optimized for feeding long-form articles into an LLM without header/footer/sidebar noise.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
max_bytesNo
timeout_msNo
user_agentNo
max_redirectsNo
allow_private_hostsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the read-only, idempotent, non-destructive annotations, the description discloses the DOM preference order, the fallback to <body>, the removal of navigation/footer/aside chrome, and the exact return shape. This gives the agent a solid model of what happens when the tool runs.

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?

Two dense sentences front-load the primary action and extraction strategy, then give the output shape and intended use case. There is no filler or repetition of schema/annotation information.

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?

The description is complete for selection and general invocation, including return fields and article-extraction strategy. However, given six parameters with no parameter descriptionsable, the absence of any guidance on network controls and limits leaves a modest completeness gap.

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

Parameters2/5

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

Schema description coverage is 0% and the description does not compensate by explaining max_bytes, timeout_ms, user_agent, max_redirects, or allow_private_hosts. While some parameter names are self-explanatory, the lack of defaults, units, or behavioral caveats leaves meaningful ambiguity for correct invocation.

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?

The description states a specific operation ('GET a URL'), a clear resource (main article body), and an exact output (markdown with title, byline, wordCount). It differentiates itself from siblings like fetch_html_to_markdown and http_get by emphasizing article-body extraction and noise removal.

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

Usage Guidelines4/5

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

The description clearly narrows use to long-form articles for LLM consumption and explains the extraction behavior, implying this is for reader-mode fetching rather than raw HTTP access. It does not name sibling alternatives or state explicit when-not-to-use conditions, so it falls short of a 5.

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