Skip to main content
Glama
kitedesk-erm

url-to-markdown-mcp

url-to-markdown-mcp

npm MCP Registry License: MIT

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_chars keeps you inside a token budget

  • Read-only and SSRF-safe: localhost and private IPs are refused

  • Small: one tool, stdio transport, and two runtime dependencies (@modelcontextprotocol/sdk and zod)

Tool

extract_url

Argument

Type

Default

Description

url

string, required

Public http(s) URL (the scheme is optional)

format

markdown | text | both

markdown

Output format

max_chars

integer

no limit

Truncate the content to N characters

links

boolean

true

Keep [text](url) links

images

boolean

false

Include ![alt](src) images

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-mcp

Cursor

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: npx

  • args: ["-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: 6000 each).

  • "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_blocked tool 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 backend

The 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.

License

MIT

Available Tools

1 tool
extract_urlExtract URL to MarkdownA
Read-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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPublic http(s) URL to read (scheme optional)
linksNoKeep [text](url) links in Markdown (default true)
formatNoOutput format (default: markdown)
imagesNoInclude ![alt](src) images in Markdown (default false)
max_charsNoTruncate the content to N characters to fit your context budget (0 = no limit)

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev1.0.0
    • First observedextract_url

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

The lone name extract_url follows a clear verb_noun pattern and is descriptive; no competing conventions to clash with.

Tool Count4/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    Not graded
    maintenance
    An 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.
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    MCP server for retrieving web pages as clean Markdown, with configurable detail levels and optional Chromium rendering for JavaScript-heavy pages.
    1
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    MCP server to scrape web pages to clean Markdown via headless Chromium, with support for single or batch URLs.
    MIT