Skip to main content
Glama

extract_web_markdown

Convert any web page into clean Markdown by removing HTML, JS, and CSS bloat, delivering LLM-ready content with token-compression analytics that cut inference token usage by about 85%.

Instructions

    [Cost: $0.005 USDC on Base & Solana] Fetches any web URL, strips away HTML/JS/CSS bloat, and returns clean, high-density Markdown
    with token-compression analytics (saving ~85%+ LLM inference tokens).
    Designed specifically for autonomous AI agents needing LLM-ready web content without token waste.

    Args:
        url: The HTTP or HTTPS URL of the webpage to scrape and convert.
        include_images: Whether to include extracted image links in Markdown format (default: False).
        payment_signature: Optional x402 Base USDC transaction hash or developer mock key.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
include_imagesNo
payment_signatureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries full burden; it discloses cost ($0.005 USDC), output transformation (strip bloat, Markdown), and token-compression analytics. It could mention failure modes or rate limits, but it covers the most decision-critical behaviors for invocation.

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 cost and core transformation, then necessary parameter descriptions. The 'Designed specifically...' sentence slightly reiterates the token-waste benefit, but overall each sentence earns its place.

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?

No output schema exists, so the description appropriately explains the return type (Markdown with token-compression analytics). It covers cost, purpose, and all parameters; minor gaps around error/edge-case behavior prevent a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters are explained in the Args section despite 0% schema coverage. url gets format constraint (HTTP/HTTPS), include_images gets output semantics and default, and payment_signature gets its x402/mock-key meaning—far beyond the bare schema names.

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?

Description uses specific verb+resource: 'Fetches any web URL... returns clean, high-density Markdown', clearly distinguishing from web search and content manipulation siblings. The 'LLM-ready web content' framing reinforces its specific function.

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?

States clear context—designed for autonomous AI agents needing LLM-ready web content from a URL without token waste. Does not explicitly enumerate when not to use it or compare to search_web/classify_url, but the 'any web URL' wording implies direct URL fetching rather than search.

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