Skip to main content
Glama

WebRead

Read a web page as Markdown

read_url
Read-only

Fetch a public web page and return its main content as clean Markdown (no navigation, scripts or ads), with title and description. Respects robots.txt. Free tier returns the first 2000 characters; the paid x402 endpoint returns up to 200,000.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute http(s) URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely new behavior: boilerplate stripping, robots.txt compliance, returned metadata fields, and — most importantly — tier-based truncation at 2,000 vs 200,000 characters. It stops short of covering failure modes (blocked by robots.txt, non-HTML URLs) and any rate-limit behavior.

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?

Two tight sentences with zero filler. The core action and return format come first, then the operational constraints (robots.txt, tier limits) in descending order of importance.

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?

With no output schema, the description correctly carries the return-value burden: Markdown body, title, description, and truncation ceiling. It also handles the auth/tier model. What's missing is what happens on failure — a blocked or unparseable page — which matters for a one-argument open-world fetch 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?

Only one parameter and schema coverage is 100%, with the schema itself stating 'Absolute http(s) URL'. The description's only added constraint is that the page must be public, which is useful but marginal. Baseline 3 is correct when the schema fully documents the single argument.

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 a public web page) plus a precise output contract: main content as clean Markdown with title and description. The parenthetical 'no navigation, scripts or ads' pins down the extraction semantics, so an agent knows exactly what comes back without opening the schema.

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?

Implies when to use it via 'public web page' (excludes authenticated/private content) and 'Respects robots.txt', which is a caller-relevant constraint. The tier note (2000 chars free vs 200,000 paid) gives a basis for choosing the endpoint, but there are no explicit exclusions such as 'do not use for PDFs or API endpoints' and no sibling alternatives to route against.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources