Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Website to Markdown MCP turn https://example.com into markdown for me"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Turn any web page into clean, structured Markdown — purpose-built for AI agents, LLM context and RAG pipelines.
No API key. No account. No pay-per-event. Runs locally over stdio.
LLMs read text, not DOM trees. This server fetches a page, strips the navigation, ads and boilerplate, and hands your agent semantic Markdown it can reason over immediately — a browser that speaks the model's language.
One command, no config — uvx website-to-markdown-mcp and it is running
Real extraction — trafilatura for article text, BeautifulSoup fallback for everything else
Batch + concurrency — up to 5 pages in flight at once, one bad URL never kills the batch
Honest output — guarantees an H1 heading, never leaks raw HTML tags
Metadata too — title, description, author, Open Graph tags, canonical URL
Related MCP server: fetch-guard
Tool | Description | Arguments |
| Fetch one page and return clean Markdown |
|
| Fetch several pages concurrently; returns |
|
| Extract title, description, author, OG tags, canonical |
|
# one-off, no installation (recommended)
uvx website-to-markdown-mcp
# or with pip
pip install website-to-markdown-mcp
# or from source
git clone https://github.com/MarekCziba/website-to-markdown-mcp
cd website-to-markdown-mcp
uv syncClaude Desktop / Claude Code — claude mcp add:
claude mcp add website-to-markdown -- uvx website-to-markdown-mcpCursor, Windsurf, or any JSON-config client:
{
"mcpServers": {
"website-to-markdown": {
"command": "uvx",
"args": ["website-to-markdown-mcp"]
}
}
}opencode (opencode.json):
{
"mcp": {
"website-to-markdown": {
"type": "local",
"command": ["uvx", "website-to-markdown-mcp"],
"enabled": true
}
}
}You: Summarise https://example.com
Agent: [calls fetch_url]
# Example Domain
This domain is for use in documentation examples without needing
permission. ...
You: Pull the title and description from three pages at once
Agent: [calls fetch_urls with 3 URLs]Your MCP client starts the server over stdio
httpx fetches the page (redirects followed, 30 s timeout, honest User-Agent)
trafilatura extracts the article body as Markdown
If extraction is too thin, boilerplate tags are stripped and markdownify takes over
The document title is re-attached as an # H1 when the extractor dropped it
uv sync # install runtime + dev dependencies
uv run pytest # runs against LIVE urls (example.com, docs.python.org, wikipedia.org)
uv run ruff check src tests
uv run ruff format src testsThe test suite asserts on actual output — expected phrases, no leaked HTML tags,
max_length enforcement, batch error isolation and URL validation — not on “it looks fine”.
MIT — see LICENSE.
Built by Marek Cziba · GitHub · LinkedIn · marekcziba@gmail.com
Extract page metadata (title, description, author, Open Graph tags).
Args: url: Absolute http(s) URL of the page to inspect.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not say whether the tool fetches the URL over the network, how redirects or unreachable/timeout URLs are handled, whether auth or robots restrictions apply, or whether a head-only request is made. 'Inspect' is the only hint about mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence naming the tool's output, followed by a compact arg note with no filler. The 'Args:' block is slightly redundant with a single obvious parameter but is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output is covered by an output schema, so return values need no explanation, and a single required parameter keeps the surface small. The remaining gap is the absent behavioral detail around network access and failure handling, which matters for a URL-fetching tool but is minor given overall simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema only types url as a bare string, so the description's 'Absolute http(s) URL of the page to inspect' meaningfully constrains the expected format. For a one-parameter tool this is adequate compensation, though it adds no detail on encoding or query-string handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Extract') and resource ('page metadata') and enumerates the extracted fields (title, description, author, Open Graph tags). It is distinguishable from fetch_url/fetch_urls, which retrieve content rather than parsed metadata, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by contrast with the sibling fetch tools: an agent can infer this is for metadata rather than full page content. There is no explicit when-to-use, when-not-to-use, or alternative routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single web page and convert it to clean Markdown.
Args: url: Absolute http(s) URL of the page to convert. max_length: Maximum number of characters of Markdown to return.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| max_length | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the core behavior (fetch + convert to Markdown) but omits important traits: whether it follows redirects, handles non-HTML content, requires network access, or what happens on failure/robots.txt. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded one-sentence purpose followed by concise parameter notes. No filler, though the Args block is somewhat redundant with the schema structure itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required. However, with no annotations and a network-facing fetch tool, the absence of any behavioral notes (redirects, errors, encoding) leaves meaningful gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It defines both parameters: url as an absolute http(s) URL, and max_length as the character cap on returned Markdown. This meaningfully fills the gap left by the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (fetch) and resource (a single web page) with the transformation (to clean Markdown). The word 'single' implicitly distinguishes it from the sibling fetch_urls, though the differentiation is not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus fetch_urls or extract_metadata. The 'single' qualifier hints at batch alternatives but does not name the condition for choosing this tool over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch several web pages concurrently and convert each to Markdown.
Args: urls: List of absolute http(s) URLs. max_length: Maximum number of characters of Markdown per page.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| max_length | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose useful traits: concurrency, per-page Markdown conversion, and per-page length capping. However, it says nothing about failure behavior (does one bad URL abort the batch?), timeouts, rate limits, or authentication, which are material for a network-fetch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence carries the purpose and behavior, followed by a compact Args block. No filler, no repetition of the tool name, and the concurrency fact appears before the parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and both parameters are covered. The remaining gap is batch edge-case behavior: no statement about result ordering, partial failures, or per-URL error reporting, which an agent needs before committing to a multi-URL call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: 'urls' is constrained to absolute http(s) URLs (a real validation rule absent from the schema), and 'max_length' is defined semantically as character count of Markdown per page, clarifying it is not bytes or tokens.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch several web pages'), plus the transformation ('convert each to Markdown') and the concurrency behavior. The plural 'several' implicitly separates it from the singular sibling fetch_url, though the distinction is left to inference rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'several web pages' suggests this is the batch counterpart to fetch_url, and extract_metadata is never mentioned. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer routing from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0extract_metadatafetch_urlfetch_urlsScored across 3 tools
fetch_url and fetch_urls share nearly identical purpose, differing only in single vs. batch input, but their descriptions make the distinction explicit. extract_metadata targets a clearly different output (page metadata) and stands apart cleanly.
All three names follow a consistent snake_case verb_noun pattern (fetch_url, fetch_urls, extract_metadata). The plural form for the batch variant is a sensible, predictable convention.
Three tools is on the lean side but well-matched to a narrow single-purpose server (web page to Markdown conversion). Each tool earns its place with no redundancy.
Covers the core surface: single fetch, concurrent batch fetch, and metadata extraction, with a sensible max_length control. Missing niceties like custom headers/auth or content-selector options, but no dead ends for the stated purpose.
Web scraping for AI agents. Converts URLs to clean, LLM-ready Markdown with anti-bot bypass.
Clean Markdown and AI-readability scoring for any URL. Built for AI agents.
Cloud scraping & crawling API for AI agents. Turn any URL into clean, LLM-ready markdown.
Web scraping for AI agents: scrape, search, crawl, map any website to markdown + JSON. No browser.