Skip to main content
Glama
telly6

searchpin

by telly6
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

web_fetch

Fetch a URL and return clean extracted text with boilerplate, ads, and navigation removed, so you can read articles, documentation pages, and API responses in full.

Instructions

Fetch a URL and return clean, extracted text content (boilerplate, ads, and nav removed). Use to read articles, documentation pages, or API responses in full. PDF text layers are extracted locally with page labels; unreadable PDFs return an explicit error. OCR is not included. For broad queries, use web_search first, then fetch specific URLs from its results. After fetching, look for technical terms, names, or references you can use as keywords for a better follow-up search.

⚠️ FAILURE IS NORMAL — DO NOT GIVE UP AFTER 1-2 FAILED FETCHES:

  • If a fetch returns empty body, 403, or obvious JS-template garbage, try the NEXT URL from the search results immediately. Each retry costs only ~0.5s.

  • Common failure causes: JS-rendered SPA shells (stock pages, forums), Chinese paywalls/captchas (wenku.baidu.com, zhihu.com), government site timeouts.

  • Rule of thumb: try at least 3 URLs from 3 different domains before concluding the content is unreachable. Skipping this wastes the search you already paid for.

  • When retrying, pick a URL from a DIFFERENT domain — same-domain failures often share the same root cause (e.g., all pages behind the same Cloudflare/WAF).

RETRY SILENTLY: When a fetch fails, retry with the next URL immediately as another tool call. Do NOT narrate each failure to the user ('this one failed, trying another…'). Only mention failures in your final reply if ALL attempts were exhausted.

Input Schema

NameRequiredDescriptionDefault
urlYesThe URL to fetch

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.8

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it discloses the extraction behavior, that PDF text layers are processed locally with page labels, that OCR is absent, that unreadable PDFs return an explicit error, and enumerates real failure modes (JS SPA shells, Baidu/Zhihu captchas, government timeouts) with an approximate retry cost of ~0.5s.

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 usage routing before the failure block, and the bolded header makes the retry rule scannable. Slightly long — the 'FAILURE IS NORMAL' and 'RETRY SILENTLY' sections partially overlap and could be merged, but no sentence is truly wasted given the operational stakes.

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 no annotations, the description still conveys what comes back (clean extracted text, page labels for PDFs, explicit error on unreadable files) and what to do when it doesn't. An agent has enough to invoke it correctly and recover from failure without further context.

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?

Only one parameter (url) and schema coverage is 100%, so the schema already documents it; the description adds nothing about URL syntax — absolute vs relative, redirect handling, or scheme restrictions. Given a single param, baseline-level credit is appropriate rather than more.

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+resource ('Fetch a URL and return clean, extracted text content') and immediately qualifies scope (boilerplate, ads, nav removed). Names its sibling web_search as the different counterpart for broad queries, so an agent can route without opening either schema.

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?

Explicit 'use web_search first, then fetch specific URLs from its results,' plus a concrete retry protocol: try at least 3 URLs from 3 different domains, prefer different domains to avoid shared WAF causes, and retry silently rather than narrating. Covers when-to-use, when-not, and the escalation path after failure.

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