url-to-markdown-mcp
url-to-markdown-mcp
npm: @kitedesk-erm/url-to-markdown-mcp · Official MCP Registry: io.github.kitedesk-erm/url-to-markdown-mcp
An MCP server that turns any URL into clean Markdown or plain text for your AI assistant. It gives Claude, Cursor, Windsurf, Cline, VS Code Copilot and any other MCP client one tool, extract_url. The tool fetches a page and returns only the main content (no nav, ads, cookie banners, sidebars, footers or comments), plus the title, author, publish date, word count and reading time.
It's backed by the hosted Article Extractor and URL to Markdown API on Zyla API Hub. You'll need a Zyla API key, and you can get one with a 7-day free trial.
Fast: p50 about 230 ms and p95 about 650 ms for extraction (20 real article URLs, measured 2026-10-22)
LLM-ready Markdown with headings, lists, code blocks and absolute links;
max_charskeeps you inside a token budgetRead-only and SSRF-safe: localhost and private IPs are refused
Small: one tool, stdio transport, and two runtime dependencies (
@modelcontextprotocol/sdkandzod)
Tool
extract_url
Argument | Type | Default | Description |
| string, required | Public http(s) URL (the scheme is optional) | |
|
|
| Output format |
| integer | no limit | Truncate the content to N characters |
| boolean |
| Keep |
| boolean |
| Include |
The tool returns a short metadata header followed by the content:
# How to Work Hard
Source: https://paulgraham.com/hwh.html
Words: 3313 (~14 min read) | truncated by max_chars
June 2021
It might not seem there's much to learn about how to work hard. Anyone who's been to school knows what it entails, ...Errors come back as MCP tool errors (isError: true) with a readable message, so the model can recover. That covers a missing key, a private or localhost URL, a non-HTML target, an unreachable site, a Zyla quota or rate limit, and the API's 502 errors: upstream_blocked (the site returned 401/403/429/451 or a bot-challenge page) and empty_content (about 0 words, for example a page rendered client-side). Zyla only bills successful calls, so blocked or empty pages aren't charged.
Related MCP server: Scrapi MCP Server
Install
You need Node.js 18 or later. Every client runs the same command, npx -y @kitedesk-erm/url-to-markdown-mcp, with your key in ZYLA_API_KEY.
Claude Desktop
Edit claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\):
{
"mcpServers": {
"url-to-markdown": {
"command": "npx",
"args": ["-y", "@kitedesk-erm/url-to-markdown-mcp"],
"env": { "ZYLA_API_KEY": "your-zyla-api-key" }
}
}
}Claude Code
claude mcp add url-to-markdown --env ZYLA_API_KEY=your-zyla-api-key -- npx -y @kitedesk-erm/url-to-markdown-mcpCursor
Use ~/.cursor/mcp.json for a global setup, or .cursor/mcp.json for a single project:
{
"mcpServers": {
"url-to-markdown": {
"command": "npx",
"args": ["-y", "@kitedesk-erm/url-to-markdown-mcp"],
"env": { "ZYLA_API_KEY": "your-zyla-api-key" }
}
}
}VS Code (GitHub Copilot agent mode)
Add this to .vscode/mcp.json. VS Code prompts for the key and stores it securely:
{
"inputs": [
{ "type": "promptString", "id": "zyla-key", "description": "Zyla API key", "password": true }
],
"servers": {
"url-to-markdown": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@kitedesk-erm/url-to-markdown-mcp"],
"env": { "ZYLA_API_KEY": "${input:zyla-key}" }
}
}
}Windsurf, Cline, Continue, Zed and other clients
Most clients take the same mcpServers block shown for Claude Desktop and Cursor (Windsurf uses ~/.codeium/windsurf/mcp_config.json; Cline uses its MCP Servers → Configure panel). The generic form is:
command:
npxargs:
["-y", "@kitedesk-erm/url-to-markdown-mcp"]env:
ZYLA_API_KEY=<your key>transport: stdio
Smithery / Docker
The repo includes smithery.yaml and a Dockerfile. You can also run it in Docker: docker build -t url-to-markdown-mcp . && docker run -i --rm -e ZYLA_API_KEY url-to-markdown-mcp.
From source
If you're installing before the npm release, build from source:
git clone https://github.com/kitedesk-erm/url-to-markdown-mcp.git
cd url-to-markdown-mcp && npm install && npm run build
# then use "command": "node", "args": ["/absolute/path/to/url-to-markdown-mcp/dist/index.js"]Example prompts
"Read https://go.dev/blog/go1.22 and summarize what changed in loops."
"Pull the text of these three articles and compare their arguments" (with
max_chars: 6000each)."Save this page as a Markdown note with title and author front matter."
Limits
No JavaScript rendering. Pages that build their content only in the browser (some SPAs) return little text.
Paywalled or bot-protected sites return only what they serve publicly. Blocked or challenged requests return an
upstream_blockedtool error and aren't billed.Your Zyla plan sets the quota and rate limit. Only successful (200) calls count against your plan.
Development
npm install
npm test # build, then the raw JSON-RPC handshake + tools/list, a tool call via a local mock Zyla gateway, and metadata checks
npm run test:live # same, but the mock gateway forwards to the live extraction backendThe tests use a fake key against a local mock, so no real key is needed or stored. The Zyla endpoint lives in one constant, src/config.ts. ZYLA_ENDPOINT overrides it, but only for testing.
Changing the GitHub handle or namespace: package.json → mcpName is the source of truth. Run npm run set-github-handle -- <handle> to rewrite package.json, server.json, README.md and smithery.yaml. npm test then checks that they all agree, which the MCP Registry also requires.
Related
url-to-markdown-api: zero-dependency JS/TS and Python clients, plus RAG, agent and read-later examples
License
Available Tools
1 toolextract_urlExtract URL to MarkdownARead-onlyIdempotent
Fetch a public web page (article, blog post, docs page, README, Wikipedia...) and return its main content as clean Markdown and/or plain text, with nav, ads, footers and comments removed, plus title, author, publish date, word count and reading time. Does not run JavaScript; paywalled pages return only public content.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL to read (scheme optional) | |
| links | No | Keep [text](url) links in Markdown (default true) | |
| format | No | Output format (default: markdown) | |
| images | No | Include  images in Markdown (default false) | |
| max_chars | No | Truncate the content to N characters to fit your context budget (0 = no limit) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld and idempotent, so safety is covered; the description adds genuinely new behavior: nav/ads/footers/comments are stripped, the page is not rendered with JavaScript, and paywalled content is truncated to the public portion. It does not mention rate limits or failure modes, which keeps it below the top score.
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?
Two tightly packed sentences with no filler: the core action and output come first, the returned metadata second, and the limitations last. Every clause carries information an agent needs.
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?
No output schema exists, and the description compensates by naming the returned fields (title, author, publish date, word count, reading time) and the cleaned-content guarantee. Combined with full schema coverage and annotations, an agent has everything needed to call this correctly and interpret the result.
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 100%, so every parameter including defaults is already documented in the schema. The description confirms the output-format duality ('Markdown and/or plain text') and the metadata returned but adds no format syntax or limits beyond what the schema provides, so baseline 3 applies.
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/extract) and resource (public web page) plus the transformation applied (main content as clean Markdown/plain text). It enumerates the content types it targets (article, blog post, docs, README, Wikipedia) so the agent knows exactly what class of input this tool serves.
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?
There are no siblings to differentiate from, and the description implicitly scopes usage via 'public web page' and the explicit caveats that it does not run JavaScript and paywalled pages return only public content. That tells the agent when the result will be degraded, but it stops short of an explicit 'use this instead when' routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
extract_url
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion; extract_url has a single, unambiguous purpose of converting a URL's main content into Markdown/text.
The lone name extract_url follows a clear verb_noun pattern and is descriptive; no competing conventions to clash with.
The server is deliberately single-purpose, so one tool earns its place, though it is at the thin end of the scale—there is no batching or format-specific variant.
For a URL-to-Markdown converter the surface is essentially complete: content extraction, nav/ad stripping, metadata, and both Markdown and text output. The stated lack of JavaScript execution and paywall handling are acknowledged limitations rather than silent gaps.
Maintenance
Related MCP Connectors
MCP server (stdio): fetch web pages as clean readable markdown via the AgentForge API
Web scraping MCP server: any URL to Markdown or JSON, with JavaScript rendering and batch jobs.
Turn any public website into an MCP server for agents to search, read and navigate.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceAn MCP server that extracts clean, structured Markdown content from web page URLs using the WebforAI library. It simplifies feeding web content into AI models by removing HTML noise and intelligently processing tables and links.-
- AlicenseAqualityCmaintenanceMCP server that converts URLs to clean Markdown/Text for LLM agents.532 npm5MIT
- AlicenseNot gradedqualityCmaintenanceMCP server for retrieving web pages as clean Markdown, with configurable detail levels and optional Chromium rendering for JavaScript-heavy pages.1MIT
- AlicenseNot gradedqualityDmaintenanceMCP server to scrape web pages to clean Markdown via headless Chromium, with support for single or batch URLs.MIT