Integrates with the Web2MD API on RapidAPI to fetch web pages and convert them into clean Markdown, plain text, token-bounded RAG chunks, or page metadata. It enables reading URL content, chunking pages for embeddings, converting raw HTML, and retrieving metadata such as title, author, date, description, language, and reading time.
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., "@If you need the name of the MCP server published by that repository, it's Web2MD MCP server. fetch https://example.com as clean Markdown"
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.
An MCP server that turns any web page into clean Markdown, plain text or token-bounded RAG chunks, using the Web2MD API on RapidAPI.
read_url: fetch a web page and return its main content as Markdown or plain text, without nav, ads or boilerplate.
chunk_url: fetch a web page and split it into heading-aware chunks sized in tokens, for RAG and embeddings.
convert_html: convert raw HTML you already have into Markdown or plain text.
page_metadata: get a page's title, author, published date, description and similar fields without the full content.
Related MCP server: urltomarkdown-mcp
Subscribe to Web2MD on RapidAPI. The BASIC plan is free and includes 500 requests per month.
Copy your X-RapidAPI-Key from the Endpoints tab of the listing.
Add the server to your client.
Requires Node.js 22 or newer.
Claude Code:
claude mcp add web2md -e RAPIDAPI_KEY=your-key -- npx -y web2md-rag-mcpClaude Desktop (claude_desktop_config.json) and Cursor (~/.cursor/mcp.json) use the same JSON:
{
"mcpServers": {
"web2md": {
"command": "npx",
"args": ["-y", "web2md-rag-mcp"],
"env": { "RAPIDAPI_KEY": "your-key" }
}
}
}Windsurf: put the same block in ~/.codeium/windsurf/mcp_config.json.
Tool | What it does | Arguments | Returns |
| Fetch a page as clean Markdown or text |
| Title, token count and the content; |
| Split a page into RAG chunks |
| JSON with |
| Convert raw HTML |
| Same as |
| Get page metadata |
| JSON with title, author, date, description, site name, language, canonical URL, image, word count, reading time |
Plan | Price | Requests per month |
BASIC | $0 | 500 |
PRO | $9 | 10,000 |
ULTRA | $29 | 60,000 |
MEGA | $79 | 250,000 |
RapidAPI rate limit: 1,000 requests per hour.
Pages up to 5 MB.
robots.txt is respected.
JavaScript-heavy pages may return no_content. Rendering support is planned.
Tool errors look like Web2MD error [code]: message. Input-validation failures (a bad URL, out-of-range numbers) come from the MCP SDK as MCP error -32602: Input validation error ... instead.
Code | Meaning |
|
|
|
|
| RapidAPI rejected the key, or you are not subscribed |
| Your plan's quota or rate limit is used up |
| The request failed validation (HTTP 422) |
| 400: not http/https, has credentials, no host, bad port, or longer than 2048 chars |
| 400: host resolves to a private, loopback, link-local or metadata address; port not 80/443; localhost/.local/.internal. Applies to every redirect |
| 400: the host does not resolve |
| 403: the site's robots.txt disallows the |
| 413: page larger than 5 MB |
| 415: not HTML |
| 422: fewer than 10 words of main content, often a JavaScript-only page |
| 429: per-target-site limit that protects the sites fetched. It is not your quota |
| 502: the site answered 401/403/429/503, often a bot wall |
| 502: the site answered another 4xx/5xx |
| 502: could not connect, or TLS failed |
| 502: more than 5 redirects |
| 504: the fetch took more than 15 s |
| The Web2MD request timed out |
| The request could not reach the API |
| The API returned a non-JSON success response |
| Any other HTTP failure, with a short snippet of the response |
| An unexpected error inside the MCP server |
Your key is sent only to the RapidAPI gateway (web2md-webpage-to-markdown-rag-chunks.p.rapidapi.com) and is never logged.
npm ci
npm test
npm run lint
npm run build
RAPIDAPI_KEY=your-key npm run smokeMIT
Fetch a web page and split its main content into heading-aware, token-bounded chunks for RAG/embeddings. Each chunk has its heading path and token count.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL, at most 2048 characters. | |
| max_tokens | No | Maximum tokens per chunk, 64-8192. Default 512. | |
| include_links | No | Keep links as [text](url). Default true. | |
| include_images | No | Keep images as . Default false. | |
| include_tables | No | Keep tables as Markdown tables. Default true. | |
| overlap_tokens | No | Tokens of overlap between chunks, 0-1024. Default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, so safety and network scope are covered. The description adds that only main content is chunked and that chunks carry heading path and token count, which is useful beyond annotations, but says nothing about failure modes (unreachable URL, robots restrictions) or content types.
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 the output shape are front-loaded. Every clause earns its place.
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, yet the description fills that gap by describing the returned chunk structure (heading path, token count). Combined with full schema coverage and annotations, an agent has nearly everything needed, though error/edge-case behavior remains unstated.
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 the schema fully documents all six parameters including defaults and ranges. The description only echoes the chunk-size and heading concepts, adding no semantics the schema does not already provide. 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?
Precise verb-and-resource plus the transformation intent: fetch a page, split main content into heading-aware, token-bounded chunks for RAG/embeddings. This clearly distinguishes it from read_url (raw content) and convert_html (format conversion).
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?
The stated purpose ('for RAG/embeddings') implies when to use it, but it never names alternatives like read_url or convert_html or states when not to use chunking. Usage is inferred rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert raw HTML you already have into clean Markdown (or plain text). Pass url to resolve relative links.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page URL, used to resolve relative links. | |
| html | Yes | Raw HTML, at most 5,000,000 characters. | |
| format | No | Output format. Default markdown. | |
| include_links | No | Keep links as [text](url). Default true. | |
| include_images | No | Keep images as . Default false. | |
| include_tables | No | Keep tables as Markdown tables. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and no-network behavior are covered. The description adds one useful behavioral detail — that url resolves relative links — but says nothing about processing limits, error behavior, or what 'clean' means.
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 short sentences, zero filler, with the core action front-loaded and the url hint as a secondary clause. Nothing to trim.
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?
For a read-only conversion utility with a fully documented schema, the description covers purpose and the main output modes. The only gap is that it omits the 'json' output format available in the enum, though the schema compensates.
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 url, format, include_links/images/tables is already documented with defaults in the schema. The description only restates the url parameter, adding no meaning beyond the structured field.
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 (Convert) and resource (raw HTML into Markdown/plain text), and the phrase 'you already have' scopes it against fetching siblings like read_url. It stops short of naming those alternatives explicitly, so an agent must infer the boundary.
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?
The 'raw HTML you already have' phrasing implies the use case (local conversion vs. retrieval), but no explicit when-to-use rule or alternative is given, and no exclusions such as 'use read_url to fetch a page first' appear. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a web page's metadata (title, author, published date, description, site name, language, canonical URL, image, word count, reading time) without the full content.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL, at most 2048 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds a genuine behavioral trait — it avoids retrieving full page content, i.e. it is the lightweight metadata-only path — and enumerates the returned shape in the absence of an output schema. It stops short of noting error behavior for invalid/non-HTML URLs or redirect handling.
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?
A single front-loaded sentence with the action and resource first, followed by the field enumeration that legitimately earns its space because no output schema documents the return shape. No filler or restatement of the tool name.
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?
For a one-parameter, read-only, open-world fetch tool with no output schema, the description covers what it returns and what it deliberately omits (full content). It is not fully complete only in that it says nothing about failure modes for unreachable or non-HTML URLs.
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?
Only one parameter exists and schema description coverage is 100% (absolute http(s) URL, max 2048 chars), so the schema carries the semantics. The description adds nothing about URL format, redirects, or trailing-slash handling beyond what is already structured, so the 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?
Specific verb ('Get') + resource ('a web page's metadata') with an explicit enumeration of the fields returned, and the phrase 'without the full content' implicitly separates it from the sibling read_url. An agent can distinguish it from read_url, chunk_url, and convert_html without opening any schema.
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?
The phrase 'without the full content' clearly signals the intended context: use this when only page metadata is needed rather than the body text. However, it never names read_url as the alternative or states an explicit when-not condition, so the routing is inferred rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a web page and return its main content as clean Markdown (or plain text), with boilerplate, nav and ads removed. Includes title and token count. Use for reading articles, docs and blog posts.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL, at most 2048 characters. | |
| format | No | Output format. Default markdown. | |
| include_links | No | Keep links as [text](url). Default true. | |
| include_images | No | Keep images as . Default false. | |
| include_tables | No | Keep tables as Markdown tables. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine behavioral context beyond that: content extraction strips boilerplate/nav/ads and the response includes a title and token count, which tells the agent what it actually receives.
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?
Three short sentences with the core behavior front-loaded and no filler. Tight and appropriately sized for a simple fetch tool, though the last sentence could be folded in without loss.
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?
For a read-only fetch tool with no output schema, the description covers purpose, transformation behavior, and returned fields. Gaps remain around truncation/size limits, JS-rendered page handling, and failure behavior, but these are not blocking 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 coverage is 100% and every parameter is documented with defaults, so the schema does the heavy lifting. The description only echoes the markdown/text output distinction (omitting the json enum value) and adds no syntax or format guidance beyond what the schema provides — baseline 3.
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 (web page) plus the transformation applied: main content returned as clean Markdown with boilerplate, nav and ads stripped. It does not name or contrast the siblings (chunk_url, convert_html, page_metadata), so an agent gets the what but not the differentiation.
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?
"Use for reading articles, docs and blog posts" gives a usable context, but there are no exclusions and no routing to alternatives such as chunk_url for oversized pages or convert_html for raw HTML. Usage is implied rather than scoped.
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.0chunk_urlconvert_htmlpage_metadataread_urlScored across 4 tools
read_url, chunk_url, page_metadata, and convert_html have clear distinct outputs: full Markdown, RAG chunks, metadata only, and conversion of raw HTML. However, read_url and chunk_url both fetch the page's main content, which could cause minor confusion if the agent does not attend to the output format.
Three tools follow a verb_noun pattern (read_url, chunk_url, convert_html), while page_metadata is a noun phrase, breaking the convention. The deviation is minor and still readable, but a name like get_page_metadata would have been more consistent.
Four tools is well-scoped for a web-to-Markdown server, covering the core actions of reading, chunking, inspecting metadata, and converting raw HTML. Each tool earns its place without redundancy or excess.
The surface covers fetching content, chunking for RAG, extracting metadata, and converting provided HTML. A minor gap is the absence of a way to fetch raw HTML from a URL for use with convert_html, but the core read/convert workflows are well supported.
Cloud scraping & crawling API for AI agents. Turn any URL into clean, LLM-ready markdown.
Any web page as clean Markdown for agents. Hosted, no install. Free tier; Pro adds JS rendering.
Clean Markdown and AI-readability scoring for any URL. Built for AI agents.
Turn any URL into clean Markdown and structured data. Scrape, crawl, search and extract.