Skip to main content
Glama

convert_to_markdown

Convert a public webpage URL into clean markdown by stripping ads, navigation, and scripts. Get token-efficient content for summarizing, extracting facts, or answering questions.

Instructions

Convert a webpage URL into clean, AI-friendly markdown by performing a live
HTTP GET (15s timeout) and stripping ads, navigation, and scripts, keeping
only the main content (capped at 3MB of source HTML).

Use this when you need to read a webpage's actual content but want to avoid
wasting tokens on HTML tags, ads, navigation menus, and scripts - or when raw
HTML parsing is causing hallucinations in downstream reasoning. Call it before
summarizing, extracting facts from, or answering questions about any arbitrary
public URL. Do NOT use it for: URLs requiring authentication/login (no cookies
or headers are sent); non-HTML resources such as PDFs, images, or other binary
files (returns "unsupported_content"); or JavaScript-rendered single-page apps
(this does a static HTML fetch, not a browser render, so client-side-only
content may come back sparse or empty). No other tool here does markdown
conversion - the sibling get_token_dump_risk is unrelated.

Failure modes returned as structured errors (never raised): "timeout" (15s
exceeded), "http_error" (non-2xx from the target site), "network_error"
(DNS/connection failure), "unsupported_content" (not HTML or over 3MB),
"invalid_url" (missing http(s):// scheme).

Args:
    url: The full absolute URL of the webpage to convert, including scheme
        (e.g. "https://example.com/article"). Relative paths are not accepted.

Returns:
    On success: {"success": true, "url", "title", "markdown", "char_count"}
    On failure: {"success": false, "error": {"type", "message"}}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes

Schema Changelog

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

  1. First observedv1.0.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses the 15s timeout, 3MB source cap, no cookies/headers sent, static-HTML behavior, and structured error modes with their meanings. It also specifies that failures are returned as structured errors, never raised, which is important invocation 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?

The description is dense but well-organized: purpose first, then use cases, exclusions, failure modes, args, and returns. Every sentence adds actionable information, and the structure makes it easy for an agent to find the relevant detail quickly.

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?

The tool has no output schema and minimal parameter schema, so the description must carry the full contract. It does: it documents the success return shape, the failure return shape, the error types, the URL format, the timeout, and the content cap. Nothing essential is missing for an agent to invoke and interpret the result.

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?

Schema coverage is 0%, but the description fully compensates for the single url parameter. It specifies that the value must be a full absolute URL including scheme, gives an example, and explicitly states that relative paths are not accepted.

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?

The description starts with a specific verb and resource: 'Convert a webpage URL into clean, AI-friendly markdown' via a live HTTP GET, then explains the transformation (stripping ads, navigation, scripts). It also explicitly differentiates this tool from its siblings, saying no other tool here does markdown conversion and that get_token_dump_risk is unrelated.

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?

The description gives clear when-to-use guidance: read a webpage's content, avoid wasting tokens on HTML/ads/navigation, and call it before summarizing or answering questions about arbitrary public URLs. It also lists explicit exclusions: authenticated URLs, non-HTML resources, and JavaScript-rendered SPAs, and names the sibling tool it is not.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/parkyucheol-del/alphapipeline'

If you have feedback or need assistance with the MCP directory API, please join our Discord server