Skip to main content
Glama

Aginx Browser

by net.aginx

fetch

Read-only

Fetch a webpage and return clean markdown/html/text. Use whenever the agent needs to READ any web page - blogs, docs, articles, JS-rendered SPAs, Cloudflare-protected sites. Static pages are served over plain HTTP (~100ms tier:"http"); pages that need JS get the full browser (tier:"browser"). render_tier selects auto (default) / http (pure HTTP, refuses the upgrade) / obscura (always browser).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to fetch
formatNoOutput format: "markdown", "html", or "text" (default: markdown)markdown
selectorNoCSS selector to extract specific content
max_charsNoMaximum characters to return (default: 50000)
use_proxyNoRoute through proxy (for blocked foreign sites)
wait_secsNoSeconds to wait for JS rendering
js_extractNoJS expression to extract from the page after rendering
render_tierNoRendering strategy: "auto" (default), "http", or "obscura"auto
tls_fingerprintNoTLS fingerprint override (stealth mode only): "chrome145", "firefox133", etc.
auto_bypass_challengeNoAuto-detect and bypass Cloudflare Turnstile challenges (default: true)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / $defs / RenderTier / oneOf
      Previous value: -[
-  {
-    "const": "auto",
-    "description": "HTTP-direct first, fall back to obscura browser. (default)",
-    "type": "string"
-  },
-  {
-    "const": "http",
-    "description": "Pure HTTP, no V8/JS. Fastest; misses JS-rendered content.",
-    "type": "string"
-  },
-  {
-    "const": "obscura",
-    "description": "Always use the obscura browser (current behaviour pre-tiering).",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "const": "auto",
+    "description": "HTTP-direct first, fall back to diting browser. (default)",
+    "type": "string"
+  },
+  {
+    "const": "http",
+    "description": "Pure HTTP, no V8/JS. Fastest; misses JS-rendered content.",
+    "type": "string"
+  },
+  {
+    "const": "obscura",
+    "description": "Always use the diting browser (current behaviour pre-tiering).",
+    "type": "string"
+  }
+]
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

The description discloses the rendering pipeline: static pages via plain HTTP at ~100ms, JS pages via full browser, and explains the render_tier behavior including that the 'http' tier 'refuses the upgrade'. This is substantial behavioral context beyond the readOnlyHint annotation and tells the agent what actually happens during a fetch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each with a distinct job: what the tool does, when to use it, and how the rendering tiers behave. No filler, and the most important scoping information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage scope, rendering behavior, and output format options, with the schema covering all parameter details. It does not explicitly address how fetch differs from session_navigate or whether results are cached, but the readOnlyHint and 'READ' framing are enough for correct invocation.

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%, so baseline is 3. The description adds a small extra nuance for render_tier ('refuses the upgrade') and summarizes the format choice, but doesn't elaborate on the other nine parameters beyond what the schema already documents.

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 ('Fetch') and resource ('a webpage') and explicitly says it returns clean markdown/html/text. It immediately frames the tool as the go-to for reading any web page, which separates it from the interactive session_* siblings and download/search.

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?

Provides an explicit when-to-use directive: 'Use whenever the agent needs to READ any web page' and lists concrete target types (blogs, docs, articles, JS-rendered SPAs, Cloudflare-protected sites). It doesn't name alternative sibling tools or spell out when-not-to-use, but the 'READ' scope is a clear boundary against interactive session tools.

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

All Aginx Browser toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools have distinct purposes, but there's overlap between session_click/click and session_eval/eval. Descriptions clarify that session_* tools operate on persistent sessions while the others are one-off, so ambiguity is low.

Naming Consistency4/5

The session_* prefix is consistently used for session-related tools (17 of 23), while the remaining tools (cache, click, download, eval, fetch, search) are single-word lowercase verbs. This is a clear pattern, though not strictly verb_noun.

Tool Count4/5

23 tools is above the typical 3-15 range but reasonable for a browser automation server that needs both one-off and session-based operations. The count is justified by the breadth of features, though it's slightly heavy.

Completeness5/5

The surface covers all major browser automation needs: navigation, clicking, typing, scrolling, screenshot, state inspection, console/network logs, cookies/storage management, JavaScript eval, waiting, and even session export. No obvious gaps for the stated purpose.

Resources