Skip to main content
Glama
guaardvark

guaardvark

by guaardvark
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fetch_url

Read-only

Read one public web page live for questions about a specific page or domain; returns title, meta description, and main text, or the most relevant passage when given a query.

Instructions

Read one public web page live, for ANY question about a specific webpage or domain (e.g. 'what's on example.com', 'read https://site.com/page'). Returns JSON {url, final_url, title, description, content, content_length}: the title ('' if the page has none), the meta description and up to ~2000 characters of main text (scripts, styles, nav, footers and asides removed; JavaScript is not run). Pass query with the user's question to get the stretch of the page that contains the most of its words instead of the top of the page. For open-ended searches use web_search; for a title and meta-description audit use analyze_website. Needs web access on in Settings (off by default), and over MCP the Guaardvark backend running; private and local addresses are refused, including after a redirect or a DNS change.

Input Schema

NameRequiredDescriptionDefault
urlYesPage URL or bare domain, e.g. 'https://example.com/pricing' or 'example.com' (https:// is added). Up to 5 redirects are followed; each hop must be a public address. The fetch gives up when the server is silent for 15 s or the whole fetch passes 45 s. Only the first 2 MB of a page are read; a page that was cut short comes back with a page_cut field saying so. A URL that is not a page (a PDF, an image, a download) is refused.
queryNoThe user's question, in their words. Its words of three or more letters or digits (common stopwords ignored) pick the ~2000-character stretch with the most of them; the top of the page is returned when there is no query, none of the words occur, or the page already fits.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"What the user wants to know from the page, in their words. When given, the returned text is the ~2000-character stretch of the page about it; without it, the top of the page, which is often navigation."New value: +"The user's question, in their words. Its words of three or more letters or digits (common stopwords ignored) pick the ~2000-character stretch with the most of them; the top of the page is returned when there is no query, none of the words occur, or the page already fits."
    • changedInput schema / properties / url / description
      Previous value: -"URL or bare domain to fetch (e.g. 'https://example.com', 'example.com', 'www.example.com'). Protocol is optional — https:// will be added automatically if missing."New value: +"Page URL or bare domain, e.g. 'https://example.com/pricing' or 'example.com' (https:// is added). Up to 5 redirects are followed; each hop must be a public address. The fetch gives up when the server is silent for 15 s or the whole fetch passes 45 s. Only the first 2 MB of a page are read; a page that was cut short comes back with a page_cut field saying so. A URL that is not a page (a PDF, an image, a download) is refused."
  2. First observedv2.9.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries real weight and delivers: JavaScript is not run, scripts/styles/nav/footers are stripped, private/local addresses are refused even after redirect or DNS change, the backend requirement is stated, and the JSON return shape is enumerated. This is far beyond what the annotation provides.

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 the routing rule, then return shape, then preconditions and refusals. The single dense paragraph earns most of its clauses, though the parenthetical CSS-stripping list and the redirect/DNS caveat could be trimmed slightly.

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?

No output schema exists, yet the description specifies every returned field (url, final_url, title, description, content, content_length) including the empty-title case and the truncation marker. Combined with the access prerequisites and refusal conditions, an agent has everything needed to call and interpret this 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% and the schema already documents redirects, timeouts, the 2 MB cap, URL refusal, and the stopword-based stretch selection. The description largely restates that same behavior, so it meets the baseline rather than adding new parameter meaning.

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 ('Read one public web page live') plus the scope ('ANY question about a specific webpage or domain'), and explicitly routes the agent away from web_search and analyze_website. An agent can distinguish this from every sibling without opening a 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?

Gives named alternatives with their selecting conditions ('For open-ended searches use web_search; for a title and meta-description audit use analyze_website'), plus a concrete example usage and the precondition that web access must be enabled.

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