Skip to main content
Glama
Sign In

Readmd

by xyz.canisell
OverviewDiscussionsAdmin

Read a web page as Markdown (paid)

read_url
Read-onlyIdempotent

Read a web page as clean Markdown for an LLM. Fetches the URL (robots.txt respected), extracts the main content (drops navigation, headers, footers, sidebars, cookie banners) and returns GitHub-flavoured Markdown with headings, lists, tables, code blocks (with language) and absolute links, plus metadata (title, description, author, published/modified dates, site name, language, canonical URL, image), an outline of headings, word count and a token estimate. Options: mode=full for the whole page, links=false to save tokens, images=true, include_links=true for the link list, max_tokens to truncate, chunk_tokens to get RAG-ready chunks with heading paths. Also converts native Markdown, plain text, JSON and RSS/Atom feeds. Never charged when it fails: unreachable or 4xx/5xx targets, robots.txt disallow, unsupported types (PDF, images) and empty/JavaScript-only pages return an error and are not settled. $0.001 per page. Costs $0.001 USDC per call via x402 (charged only on success). Without an x402 wallet you get the payment terms and the paid HTTP URL instead.

Input Schema

NameRequiredDescriptionDefault
urlYesPublic http(s) URL of the page to read.
modeNo"main" (default): the article / main content only, without navigation, headers, footers, sidebars and cookie banners. "full": the whole page body.
linksNoKeep inline links as [text](url) in the Markdown. Default true; false saves tokens.
imagesNoKeep images as ![alt](src). Default false.
max_tokensNoTruncate the Markdown to about this many tokens, at a paragraph boundary (`truncated` tells you). Default: no limit (400k characters max).
chunk_tokensNoAlso return `chunks`: the Markdown split at headings/paragraphs into pieces of at most about this many tokens, each with its heading path. For RAG.
include_linksNoAlso return `links`: every link in the content as {url, text} (up to 500). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Goes well beyond the annotations (which already declare readOnly/idempotent/openWorld/non-destructive): robots.txt is respected, non-HTML types are supported, and the failure policy is explicit — unreachable targets, 4xx/5xx, robots disallow, PDFs/images and JS-only pages error out and are not charged. Pricing and the x402 payment flow, including the no-wallet fallback, are fully disclosed.

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

Conciseness3/5

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

Front-loaded correctly, with purpose and output described first. But it is one dense run-on paragraph, and the pricing statement is duplicated ('$0.001 per page' followed by '$0.001 USDC per call via x402'), plus the options list echoes the schema verbatim.

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 carries the return-value burden and does so thoroughly: Markdown structure, metadata fields, outline, word count, token estimate, truncation flag and optional chunks/links. Failure modes and billing conditions complete the picture an agent needs before paying for a call.

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 coverage is 100%, so every parameter is already documented in the schema with default values and semantics. The description's 'Options:' sentence largely restates those defaults rather than adding new meaning; it contributes cost/truncation context but no syntax or edge-case detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a precise verb+resource: 'Read a web page as clean Markdown for an LLM', and the body specifies extraction behavior and output format. It never names the siblings (read_urls, preview_url) to draw the single-vs-batch or preview-vs-full distinction, so the boundary is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is present at the parameter level ('mode=full for the whole page', 'links=false to save tokens', 'chunk_tokens to get RAG-ready chunks'), which implies when to pick which option. However, there is no guidance on when to choose this tool over read_urls or preview_url, which is the main selection question given the sibling set.

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

All Readmd 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