Skip to main content
Glama
deenesjakoruzh
dazeb

Markdown Downloader

by dazeb
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

Markdown ダウンローダー MCP サーバー

鍛冶屋のバッジ

概要

Markdown Downloaderは、WebページをMarkdownファイルとして簡単にダウンロードできる強力なMCP（Model Context Protocol）サーバーです。r.jina.aiサービスを活用することで、WebコンテンツをMarkdown形式にシームレスに変換できます。

Related MCP server: crawl-mcp-server

特徴

  • 🌐 r.jina.ai を使用してウェブページをマークダウンとしてダウンロードする

  • 📁 設定可能なダウンロードディレクトリ

  • 📝 日付スタンプ付きのファイル名を自動生成します

  • 🔍 ダウンロードしたマークダウンファイルを一覧表示する

  • 💾 永続的な構成

前提条件

  • Node.js (バージョン 16 以上)

  • npm (ノード パッケージ マネージャー)

インストール

Smithery経由でインストール

Smithery経由で Claude Desktop 用の Markdown Downloader を自動的にインストールするには:

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をダウンロードする

Web ページを Markdown ファイルとしてダウンロードします。

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

  • URLの先頭にr.jina.aiが付加されます。

  • ファイル名の形式: {sanitized-url}-{date}.md

  • 設定されたダウンロードディレクトリに保存されます

3. ダウンロードしたファイルのリスト

ダウンロードしたすべてのマークダウン ファイルを一覧表示します。

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を使用してマークダウンコンテンツを取得します。

  • ローカルファイルはサニタイズされたファイル名で保存されます

  • 設定可能なダウンロードディレクトリにより柔軟性が向上

貢献

貢献を歓迎します！お気軽にプルリクエストを送信してください。

ライセンス

このプロジェクトは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