Skip to main content
Glama
Sign In

Web Fetch

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Fetch Url

fetch_url
Read-onlyIdempotent

Fetch the exact contents of ONE public web URL live from its origin server and return them verbatim with a SHA-256 hash of the bytes received. Use it to read a specific page, raw data file (CSV, TSV, .dat, JSON, XML), API endpoint or PDF whose address you already know. format "auto" (default) returns readable text for HTML and PDF and the raw body for everything else; "raw" returns the body itself (decoded text, or base64 for binary such as zip/xlsx); "text" forces text extraction. Large bodies page with max_bytes and offset. Also returns url_final, the redirect chain, status, response headers, charset and how it was chosen. Refusals are explicit: blocked_url (private address, disallowed port or scheme, credentials in the URL), upstream_refused (the site answered 401/403/429 or a bot wall; the response names archive_evidence as a place to look for a capture), upstream_down, upstream_status (e.g. 404). Does not run JavaScript, log in, send cookies or search; for a past version of a page use archive_evidence. Keyless.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "https://data.giss.nasa.gov/gistemp/tabledata_v4/GLB.Ts+dSST.csv",
      "max_bytes": 2000
    },
    "name": "fetch_url"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe absolute http(s) URL to fetch, e.g. "https://data.giss.nasa.gov/gistemp/tabledata_v4/GLB.Ts+dSST.csv". http:// is tried over https first.
formatNoauto (default): text for HTML and PDF, raw for everything else. raw: the body as received. text: readable text extracted from HTML/PDF.
offsetNoWhere the window starts: a byte offset into the body (raw), or a character offset into the extracted text (text). Use next_offset from the previous call to page. Default 0.
max_bytesNoSize of the returned window. Default 100000. Maximum 1000000 for text, 512000 for base64 (binary).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds substantive behavior beyond them: explicit refusal codes (blocked_url, upstream_refused, upstream_down, upstream_status), what triggers each, redirect/header/hash return fields, paging limits, binary handling (base64 for zip/xlsx), and 'Keyless'. An agent knows exactly what can go wrong and why.

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 the core action and scope, and every clause carries information (refusals, return fields, limits). It is densely packed with semicolon-separated clauses, which costs a little readability but almost nothing is wasted.

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, the description compensates by enumerating return fields (url_final, redirect chain, status, response headers, charset, hash) and enumerating failure modes. For a 4-param open-world fetch tool, nothing an agent needs to call it or interpret results is missing.

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% and each param is already documented, so the baseline is 3. The description adds the semantic interplay the schema doesn't spell out — that the three format modes govern whether offset/max_bytes operate on bytes vs extracted characters, and that paging is driven by next_offset from the prior call.

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 the exact contents of ONE public web URL live from its origin server') plus the output shape (verbatim bytes + SHA-256 hash). It also explicitly distinguishes itself from the sibling archive_evidence by scope (live vs past version).

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 concrete when-to-use cases (known address for a page, raw data file, API endpoint, PDF) and explicit when-not cases: no JavaScript, no login, no cookies, no searching, and 'for a past version of a page use archive_evidence'. The alternative is named with the condition that selects it.

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

All Web Fetch toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources