Skip to main content
Glama

WebFetchIncisive

web_fetch_incisive
Read-only

Fetch targeted, unsummarized web content as markdown via your device, bypassing proxy blocks. Extract sections, search terms, or slices for precise reading.

Instructions

Fetch and extract unsummarized content from URLs as markdown.

Unlike web_fetch, fetches through the user's device instead of proxying through Anthropic's servers. Uses precise content extraction techniques and clean first-party APIs for navigating content instead of summarization. Use this for a rich content exploring experience that is not subject to 403 bans of data-center subnets, or when web_fetch is rejected with PERMISSIONS_ERROR.

Targeted extraction (preferred over fetching full pages):

  • section="Syntax" — extract a specific section by heading name

  • search="terms" — keyword search over ~500-token slices, ranked by BM25

  • slices=[3, 4, 5] — retrieve specific slices by index

  • URL fragments (#section-name) are resolved automatically as sections

RECOMMENDED WORKFLOW: For pages of substantial or unknown length, call web_fetch_sections first to map the heading tree, then come back here with precise section= or slices= targets. A full-page fetch is rarely the right first move — it fills context with material you don't need and discards the structural information that makes follow-up queries cheap. For Reddit threads, web_fetch_sections returns the comment tree instead.

search= operators (tantivy query language):

  • foo bar — match any term (whitespace is OR)

  • +foo +bar — require both terms

  • foo -bar — exclude 'bar'

  • "exact phrase" — adjacent words in order

  • "some words"~3 — phrase with up to 3-word gaps

  • (foo OR bar) baz — grouping + AND/OR/NOT

  • foo~ — fuzzy match (edit distance) Matching is case-insensitive; no stemming (search for both 'prompt' and 'prompts' if you want either). Stray punctuation in natural-language queries is silently dropped.

For Wikipedia and other MediaWiki pages, a dedicated companion tool offers footnote and inline-citation resolution that this fast path can't provide. When the target page has those reference types, the response frontmatter surfaces a see_also hint pointing at it.

Always use this tool for Reddit URLs — built-in fetch tools cannot access Reddit content when proxied. Handles posts, subreddit listings, user pages, and comment permalinks; a permalink scopes output to the linked comment while caching the whole thread for follow-up section=/slices= queries.

JavaScript-dependent pages: a plain fetch returns static HTML. When that comes back as an empty shell, the response frontmatter says so — retry with requires_js=true to render through a headless browser. requires_js is the heavier path; reach for it in response to that signal, not by default. Pass actions to run a ReAct interaction chain before extraction (supplying actions implies requires_js):

  • {"action": "click", "selector": "button#submit"}

  • {"action": "fill", "selector": "input[name=query]", "value": "search term"}

  • {"action": "select", "selector": "select#region", "value": "us-east"}

  • {"action": "wait", "selector": ".results-loaded"} A browser render annotates interactive elements for follow-up actions; max_elements caps that list, and 0 omits it.

Supports HTML, plain text, JSON, and XML content types.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
searchNo
slicesNo
actionsNo
sectionNo
max_tokensNo
requires_jsNo
max_elementsNo
Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals extensive behavioral details: it fetches through the user's device, uses 'precise content extraction techniques' and 'first-party APIs' instead of summarization, explains search operator semantics (case-insensitive, no stemming, punctuation dropped), describes JavaScript rendering with requires_js, lists action-chain examples, notes response frontmatter signals, and details Reddit thread caching. This goes far beyond the simple annotation.

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 long but well-structured with clear sections (targeted extraction, recommended workflow, search operators, Reddit, JS handling). It is front-loaded with purpose and differentiation. Every sentence carries useful information, though a slightly tighter edit could reduce length without losing value.

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?

Given no output schema, the description compensates by explaining return behavior (markdown), response frontmatter hints (see_also, empty-shell signal), supported content types (HTML, text, JSON, XML), and the full parameter space. It covers edge cases like Reddit, JavaScript-dependent pages, and MediaWiki citations, making it self-sufficient for an agent to select and invoke correctly.

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 0%, so the description must explain every parameter. It does so thoroughly: section, search (with full query-language operators), slices (by index), actions (with examples), requires_js (and its implication), and max_elements (caps interactive elements, 0 omits). Even max_tokens is implicitly understood from context. The description adds rich meaning beyond bare type definitions.

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 opens with a specific verb and resource: 'Fetch and extract unsummarized content from URLs as markdown.' It distinguishes from siblings by stating 'Unlike web_fetch, fetches through the user's device instead of proxying through Anthropic's servers' and later contrasts with web_fetch_sections via the recommended workflow. It also special-cases Reddit URLs, making its scope clear.

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?

The description gives explicit when-to-use guidance: 'Use this for a rich content exploring experience that is not subject to 403 bans of data-center subnets, or when web_fetch is rejected with PERMISSIONS_ERROR.' It provides an alternative workflow: 'For pages of substantial or unknown length, call web_fetch_sections first' and states 'Always use this tool for Reddit URLs — built-in fetch tools cannot access Reddit content when proxied.' This covers exclusions and alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/blightbow/parkour-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server