Skip to main content
Glama

fetch

Destructive

Retrieve a single URL as clean markdown, including specific sections, authenticated pages, or JS-rendered content while reusing local cache.

Instructions

Fetch a single URL and return clean markdown. Use when you already have a URL. Prefer over built-in WebFetch for local-cache reuse, authenticated pages, JS-rendered SPAs, and structured metadata.

Key parameters:

  • section: extract content under a specific heading (e.g. "API Reference") — cheaper than the whole page.

  • max_content_chars: smart-truncate at a paragraph/heading boundary with [... content truncated].

  • max_tokens_out: token-budget cap (cl100k-base); wins over max_chars.

  • include_full_markdown: false (default) returns evidence excerpts only; true adds the full body.

  • use_auth: reuse a stored browser session for logged-in pages.

  • render_js: "auto" (default) | "always" | "never".

  • force_refresh: bypass cache and re-fetch.

  • mode: 'cache' | 'default' | 'stealth'. cache=HTTP-only, 24h-stale accepted. stealth=full browser + freshness.

Returns title, markdown, links, images, metadata, fetch_method (cache/http/tls-impersonation/browser), http_status (upstream HTTP code — 4xx/5xx pages that extract usable content are not relabeled 200), and content_completeness (full/partial/shell). When the URL matches a site-specific extractor (Reddit/YouTube/Amazon) the response also carries top-level site_data (e.g. Reddit comments[], YouTube caption_tracks[], Amazon price). When section is set and no heading matches, metadata.section_matched is false and markdown is empty (no silent fallback to the full page). Repeat fetches are instant. Localhost URLs work. Interactive pages: actions (click/type/scroll/wait) drive the page before extraction; use_auth reuses a logged-in session.

Input Schema

NameRequiredDescriptionDefault
urlYesURL to fetch
modeNocache=HTTP-only, accepts stale cache. default=standard fetch with JS detection. stealth=full browser render.
actionsNoSequential browser actions to perform before extracting content. When present, forces browser rendering (bypasses HTTP-first routing).
headersNoAdditional HTTP headers
sectionNoExtract a specific section by heading text
use_authNoUse stored auth credentials (default: false)
max_charsNoMaximum characters to return (hard slice)
render_jsNoJavaScript rendering mode (default: auto)
screenshotNoCapture a screenshot (default: false)
force_refreshNoBypass cache and fetch fresh content from the network. Use for rapidly changing pages (news, changelogs, dashboards).
section_indexNoIndex of the section match (default: 0)
max_tokens_outNoToken-budget cap on total output. Uses cl100k-base BPE; non-OpenAI tokenizer counts may drift ~5-15%. When both max_tokens_out and max_chars are set, max_tokens_out wins.
citation_formatNoCitation rendering style. 'numbered' (default) inline [N] markers; 'json' returns a citations[] array; 'anthropic_tags' wraps sources in <source id='...'> tags.
max_content_charsNoSmart truncate markdown to N chars at paragraph/heading boundary with [... content truncated] marker. Preferred over max_chars for AI agents.
include_full_markdownNoInclude full markdown body in the response. Default false on multi-result tools (returns evidence excerpts only); set true to restore.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.1
  2. Removedv0.2.0
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

No output schema exists, yet the description discloses return fields (title, markdown, links, metadata, fetch_method, http_status, content_completeness), site-specific site_data, cache staleness semantics, and the explicit no-match behavior for `section`. It does not address the destructiveHint=true side — that `actions` (click/type) can mutate the target page — nor rate limits, which is a real gap for a tool annotated destructive.

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?

Front-loaded with purpose and routing, then a bulleted parameter list and a returns paragraph — easy to scan. Several bullets restate schema descriptions verbatim (mode, render_js, use_auth), which is waste given 100% schema coverage, but nothing is buried or redundant in a harmful way.

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?

For a 15-parameter, nested-object, open-world tool with no output schema, the description still covers return shape, cache/freshness behavior, auth session reuse, JS rendering, failure semantics for `section`, and repeat-fetch speed. An agent has enough to call it correctly on first attempt.

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 decision guidance beyond the schema: `section` is cheaper than the whole page, `max_content_chars` truncates smartly vs `max_chars` hard slicing, `max_tokens_out` wins, and `include_full_markdown: false` returns excerpts only. It omits any mention of `citation_format`, `headers`, `screenshot`, or `section_index`.

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 single URL and return clean markdown') and immediately delimits scope with 'Use when you already have a URL', which separates it from sibling search/crawl tools. An agent can pick it 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 Guidelines4/5

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

Gives a clear selection condition ('when you already have a URL') and names an alternative it beats (built-in WebFetch) with four concrete reasons. It never states when *not* to use it or routes to siblings like crawl/extract, so it stops short of full routing guidance.

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