web2md-mcp
Click on "Install 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., "@web2md-mcpfetch https://example.com/blog/post"
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.
web2md-mcp
MCP server that fetches any web URL and converts it to clean Markdown via the web2md service (Crawl4AI backend). Designed to be hosted on the ModelScope MCP Hub so any pure-network MCP client can call it without running anything locally.
What it does
Exposes one tool fetch(url, quality, anti_bot) → returns
{success, markdown, html, metadata}. It does not bundle Crawl4AI; it
calls the already-deployed web2md REST API (/v1/fetch), so the hosted image
stays tiny and deploys fast.
Related MCP server: MCP HTTP Fetcher Server
ModelScope MCP Hub — 可托管部署 (recommended)
Per the official MCP creation doc, hosted deployment of a Python server requires
a PyPI package invoked via uvx (GitHub/Docker sources are NOT supported
for hosted deployment). This package is published to PyPI as web2md-mcp.
Create the MCP service (自定义创建 → 可托管部署) and paste this STDIO config.
The Hub auto-extracts the env block into its env-var form:
{
"mcpServers": {
"web2md": {
"command": "uvx",
"args": ["web2md-mcp"],
"env": {
"WEB2MD_BASE": "https://seaair-web2md.ms.show",
"WEB2MD_API_KEY": "<WEB2MD_API_KEY>"
}
}
}
}The Hub runs uvx web2md-mcp inside its FC runtime (STDIO transport), connects,
and exposes a public endpoint https://mcp.api-inference.modelscope.net/<id>/mcp.
Fill the real key in <WEB2MD_API_KEY> when creating.
Note: the config JSON must contain no comments — the Hub's validator rejects commented JSON.
Self-host (local / Docker, optional)
pip install web2md-mcp
WEB2MD_API_KEY=web2md-bcce3f564124cb40ff41244b6597a209 web2md-mcp
# then point your client at the resulting MCP server (stdio)Or build the Docker image (for your own registry / FC custom image):
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY web2md_mcp.py .
CMD ["python", "web2md_mcp.py"]Env vars
Key | Default | Description |
|
| web2md REST base URL |
| (empty) | your web2md API key |
Tool
fetch(url, quality="fast", anti_bot="auto") → {success, markdown, html, metadata}
Available Tools
1 toolfetchA
Fetch a web page URL and return its main content as clean Markdown.
Uses the web2md service (Crawl4AI) behind the scenes. Best for feeding article / documentation text into an LLM or RAG pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | target web page URL to fetch and convert. | |
| quality | No | 'fast' = Crawl4AI raw Markdown (complete body text). | fast |
| anti_bot | No | crawling strategy — 'auto' (default, undetected+stealth), 'stealth', 'undetected', or 'proxy'. | auto |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool uses the web2md service (Crawl4AI) and returns main content as clean Markdown. However, it does not cover failure modes, dynamic rendering, rate limits, or other behavioral traits that might affect usage.
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?
The description is two sentences long. The first sentence front-loads the action and result, and the second adds useful context about the backend and use case. Every word 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?
The tool has a straightforward purpose, an output schema, and well-documented parameters. The description covers the main purpose, use case, and underlying service. Minor gaps exist around error handling and edge cases, but these are not critical given the schema depth.
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%, with each parameter (url, quality, anti_bot) individually described. The description adds little beyond the schema—only clarifying the output format (Markdown). Since the schema already does the heavy lifting, the baseline score of 3 is appropriate.
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?
The description clearly states the tool fetches a web page URL and returns its main content as clean Markdown. This is a specific verb+resource+outcome combination. Although there are no sibling tools to distinguish from, the purpose is unambiguous and actionable.
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 description explicitly names the ideal use case: 'feeding article / documentation text into an LLM or RAG pipeline.' This provides clear context for when to use the tool. However, it does not mention exclusions or alternatives, which would be necessary for a 5.
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
v0.1.0- First observed
fetch
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion or overlap. The tool's purpose is clearly defined and distinct.
With a single tool named 'fetch', there is no inconsistency or mixed conventions. The name is a clear verb that matches its action.
A single tool is on the thin side, but it is appropriate for a focused web-to-Markdown service. The minimal surface aligns with the server's narrow scope, though more tools could be added for broader utility.
The fetch tool fully covers the stated purpose of converting a web page to clean Markdown. There are no obvious gaps for the core use case, as the operation is self-contained.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Fetch any URL and get clean Markdown. Web scraping for AI agents.
Converts any URL to clean, LLM-ready Markdown using real Chrome browsers
Web scraping for AI agents. Converts URLs to clean, LLM-ready Markdown with anti-bot bypass.
Read any web page as clean Markdown for AI agents: fetch, search, metadata, links. SSRF-safe.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceExtracts clean, structured Markdown text from web pages using WebforAI, making web content easily accessible for AI model consumption through the Model Context Protocol.MIT
- AlicenseNot gradedqualityFmaintenanceFetches web pages from HTTP/HTTPS URLs and converts them to Markdown format. Supports both SSE and Stdio protocols for web deployments, Kubernetes environments, and desktop clients.Apache 2.0
- AlicenseAqualityDmaintenanceConverts URLs and raw HTML to clean Markdown, enabling AI assistants to read web pages for summarization, analysis, or ingestion.2101MIT
- AlicenseNot gradedqualityBmaintenanceConverts web pages to Markdown for MCP clients like Claude, with support for single and batch reads, caching, fallback rendering, and SSRF protection.17MIT