Skip to main content
Glama
deenesjakoruzh
dazeb

Markdown Downloader

by dazeb
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

Markdown 下载器 MCP 服务器

铁匠徽章

概述

Markdown 下载器是一款功能强大的 MCP（模型上下文协议）服务器，可让您轻松将网页下载为 Markdown 文件。该工具利用 r.jina.ai 服务，提供将网页内容无缝转换为 Markdown 格式的便捷方式。

Related MCP server: crawl-mcp-server

特征

  • 🌐 使用 r.jina.ai 将网页下载为 markdown

  • 📁 可配置的下载目录

  • 📝 自动生成带日期戳的文件名

  • 🔍 列出已下载的 Markdown 文件

  • 💾 持久配置

先决条件

  • Node.js（版本 16 或更高版本）

  • npm（Node 包管理器）

安装

通过 Smithery 安装

要通过Smithery自动安装 Claude Desktop 的 Markdown 下载器：

npx -y @smithery/cli install @dazeb/markdown-downloader --client claude

手动安装

  1. 克隆存储库：

    git clone https://github.com/your-username/markdown-downloader.git
cd markdown-downloader

  2. 安装依赖项：

    npm install

  3. 构建项目：

    npm run build

手动将服务器添加到 Cline/Roo-Cline MCP 设置文件

Linux/macOS

{
  "mcpServers": {
    "markdown-downloader": {
      "command": "node",
      "args": [
        "/home/user/Documents/Cline/MCP/markdown-downloader/build/index.js"
      ],
      "disabled": false,
      "alwaysAllow": [
        "download_markdown",
        "set_download_directory"
      ]
    }
  }
}

视窗

{
  "mcpServers": {
    "markdown-downloader": {
      "command": "node",
      "args": [
        "C:\\Users\\username\\Documents\\Cline\\MCP\\markdown-downloader\\build\\index.js"
      ],
      "disabled": false,
      "alwaysAllow": [
        "download_markdown",
        "set_download_directory"
      ]
    }
  }
}

工具和用法

1.设置下载目录

更改下载目录：

use set_download_directory /path/to/your/local/download/folder

  • 验证目录存在且可写

  • 保留配置以供将来使用

2. 下载 Markdown

将网页下载为 markdown 文件：

use tool download_markdown https://example.com/blog-post

  • URL 前面会加上r.jina.ai

  • 文件名格式： {sanitized-url}-{date}.md

  • 保存在配置的下载目录中

3.列出已下载的文件

列出所有下载的 markdown 文件：

use list_downloaded_files

4. 获取下载目录

检索当前下载目录：

use get_download_directory

配置

Linux/macOS

  • 配置存储在~/.config/markdown-downloader/config.json

  • 默认下载目录： ~/.markdown-downloads

视窗

  • 配置存储在%APPDATA%\markdown-downloader\config.json

  • 默认下载目录： %USERPROFILE%\Documents\markdown-downloads

故障排除

  • 确保您拥有有效的互联网连接

  • 检查 URL 是否有效且可访问

  • 验证下载目录的写入权限

安全

  • 该工具使用 r.jina.ai 获取 markdown 内容

  • 本地文件以经过清理的文件名保存

  • 可配置的下载目录允许灵活性

贡献

欢迎贡献代码！欢迎提交 Pull 请求。

执照

本项目遵循 MIT 许可证。详情请参阅 LICENSE 文件。

免责声明

此工具按原样提供。请务必检查下载内容的准确性和适当性。

支持

对于问题或功能请求，请在 GitHub 存储库上打开问题。

Available Tools

5 tools
create_subdirectoryC

Create a new subdirectory in the root download folder

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the subdirectory to create

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a subdirectory, implying a write operation, but doesn't specify whether this requires permissions, what happens if the subdirectory already exists, or if there are rate limits. This is a significant gap for a mutation tool with zero annotation coverage.

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?

The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded with the core action and location, making it easy for an agent to parse quickly. Every part of the sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It doesn't address potential errors, return values, or behavioral nuances like overwrite policies. For a tool that modifies the filesystem, this lack of context is inadequate.

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?

The input schema has 100% description coverage, with the 'name' parameter clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as naming constraints or examples. Since the schema 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a new subdirectory') and specifies the location ('in the root download folder'), which distinguishes it from sibling tools like 'set_download_directory' or 'list_downloaded_files'. However, it doesn't explicitly differentiate from 'get_download_directory' in terms of creation vs. retrieval, which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'set_download_directory' or 'get_download_directory'. It lacks any mention of prerequisites, such as needing the root download folder to exist, or exclusions, such as not being able to create nested subdirectories beyond the root. This leaves the agent with minimal context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

download_markdownC

Download a webpage as markdown using r.jina.ai

ParametersJSON Schema
NameRequiredDescriptionDefault
subdirectoryNoOptional subdirectory to save the file in
urlYesURL of the webpage to download

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool downloads a webpage as markdown, implying a read operation that fetches and converts content, but lacks details on permissions, rate limits, error handling, or what happens after download (e.g., where files are saved). This is a significant gap for a tool with potential network and file system interactions.

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?

The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('download a webpage as markdown') and includes only essential technical detail ('using r.jina.ai'). Every word earns its place, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (involving web scraping and file output), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the download process (e.g., success/failure states, file naming conventions, or markdown conversion quality), leaving the agent with insufficient context for reliable use.

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%, with clear descriptions for both parameters: 'url' as the webpage URL and 'subdirectory' as an optional save location. The description doesn't add any meaning beyond this, such as URL format requirements or subdirectory path examples. Given the high schema coverage, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('download a webpage as markdown') and the resource ('webpage'), using the specific verb 'download' and specifying the output format 'markdown'. It also mentions the service used ('r.jina.ai'), which adds technical context. However, it doesn't explicitly distinguish this tool from its siblings (e.g., list_downloaded_files), which would require a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid URL), exclusions (e.g., unsupported webpage types), or comparisons to sibling tools like create_subdirectory or get_download_directory. This leaves the agent without context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_download_directoryB

Get the current download directory

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is to 'Get', implying a read-only operation, but doesn't specify if this requires permissions, what happens if no directory is set (e.g., returns null or error), or any rate limits. This leaves significant gaps in understanding the tool's behavior.

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?

The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. Every part of the sentence directly contributes to understanding the tool's purpose, earning its place effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and no output schema, the description should compensate by providing more context, such as what the return value looks like (e.g., a string path or error message) or behavioral details. It only states the action, leaving the agent unsure about the output format or potential edge cases, making it incomplete for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it implicitly confirms no inputs are required by focusing on the action alone. A baseline of 4 is appropriate as it adequately handles the lack of parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('current download directory'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'set_download_directory' or 'list_downloaded_files', which would require explicit comparison, so it falls short of a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'list_downloaded_files' or 'set_download_directory'. It lacks any context about prerequisites, such as whether a download directory must be set first, or when this tool is appropriate over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_downloaded_filesC

List all downloaded markdown files

ParametersJSON Schema
NameRequiredDescriptionDefault
subdirectoryNoOptional subdirectory to list files from

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't specify whether it returns metadata like file sizes or timestamps, how it handles errors, or if there are any rate limits. This leaves significant gaps for a tool with no structured safety hints.

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?

The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the list output looks like (e.g., file names, paths, formats) or address potential complexities like pagination or error handling. For a list tool with no structured output, more context is needed.

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?

The input schema has 100% description coverage, clearly documenting the optional 'subdirectory' parameter. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without compensating value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List') and resource ('downloaded markdown files'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_download_directory' which might also provide file-related information, so it doesn't reach the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get_download_directory' or 'download_markdown'. It doesn't mention prerequisites, exclusions, or specific contexts where this tool is preferred, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_download_directoryB

Set the main local download folder for markdown files

ParametersJSON Schema
NameRequiredDescriptionDefault
directoryYesFull path to the download directory

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool sets a directory but does not explain whether this requires specific permissions, if changes are permanent or reversible, what happens to existing files, or any error conditions. This leaves significant gaps for a mutation tool.

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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate but lacks depth. It covers the basic action but misses behavioral details like side effects or usage context, which are important for a mutation tool without annotations.

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?

The input schema has 100% description coverage, clearly documenting the 'directory' parameter as a full path. The description adds no additional meaning beyond the schema, such as format examples or constraints, but the schema's completeness justifies the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set') and the target ('main local download folder for markdown files'), providing a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like 'get_download_directory' or 'create_subdirectory', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as 'create_subdirectory' for creating subfolders or 'get_download_directory' for retrieving the current setting. It lacks explicit context, prerequisites, or exclusions, offering only a basic functional statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap. create_subdirectory handles folder creation, download_markdown performs the core download function, get_download_directory and set_download_directory manage configuration, and list_downloaded_files provides file enumeration. An agent can easily distinguish between these operations.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with clear, descriptive names. The naming convention is uniform throughout (e.g., create_subdirectory, download_markdown, get_download_directory), making the tool set predictable and easy to understand.

Tool Count5/5

With 5 tools, this server is well-scoped for its purpose of downloading and managing markdown files. Each tool serves a specific, necessary function without redundancy, making the count appropriate and efficient for the domain.

Completeness4/5

The tool set covers the core workflows of downloading, listing, and managing directories for markdown files. A minor gap exists in operations like updating or deleting downloaded files, but agents can work around this, and the surface is largely complete for the stated purpose.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

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

Related MCP Servers

  • MD Webcrawl MCP

    jmh108
    A
    license
    Not graded
    quality
    D
    maintenance
    A Python-based MCP server that crawls websites to extract and save content as markdown files, with features for mapping website structure and links.
    4
    MIT

  • crawl-mcp-server

    Git-Fg
    F
    license
    Not graded
    quality
    Not graded
    maintenance
    An MCP server for web content extraction that converts HTML pages into clean, LLM-optimized Markdown using Mozilla's Readability. It supports batch processing, intelligent multi-page crawling, and configurable caching while respecting robots.txt standards.
    43

  • WebforAI Text Extractor

    MCP-Mirror
    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.

  • web-reader

    PPParticle
    A
    license
    Not graded
    quality
    B
    maintenance
    A self-hosted MCP server that reads web pages and converts them to Markdown, with built-in web search and anti-crawl fallback using Playwright.
    1
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dazeb/markdown-downloader'

If you have feedback or need assistance with the MCP directory API, please join our Discord server