Skip to main content
Glama
deenesjakoruzh
dazeb

Markdown Downloader

by dazeb
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

마크다운 다운로더 MCP 서버

대장간 배지

개요

마크다운 다운로더는 웹페이지를 마크다운 파일로 손쉽게 다운로드할 수 있는 강력한 MCP(모델 컨텍스트 프로토콜) 서버입니다. r.jina.ai 서비스를 활용하여 웹 콘텐츠를 마크다운 형식으로 원활하게 변환할 수 있습니다.

Related MCP server: crawl-mcp-server

특징

  • 🌐 r.jina.ai를 사용하여 마크다운으로 웹페이지를 다운로드하세요

  • 📁 구성 가능한 다운로드 디렉토리

  • 📝 날짜가 찍힌 파일 이름을 자동으로 생성합니다.

  • 🔍 다운로드한 마크다운 파일 목록

  • 💾 영구 구성

필수 조건

  • Node.js(버전 16 이상)

  • npm(노드 패키지 관리자)

설치

Smithery를 통해 설치

Smithery를 통해 Claude Desktop용 Markdown Downloader를 자동으로 설치하려면:

지엑스피1

수동 설치

  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 설정 파일에 수동으로 서버 추가

리눅스/맥OS

{
  "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. 마크다운 다운로드

웹페이지를 마크다운 파일로 다운로드:

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

구성

리눅스/맥OS

  • 구성은 ~/.config/markdown-downloader/config.json 에 저장됩니다.

  • 기본 다운로드 디렉토리: ~/.markdown-downloads

윈도우

  • 구성은 %APPDATA%\markdown-downloader\config.json 에 저장됩니다.

  • 기본 다운로드 디렉토리: %USERPROFILE%\Documents\markdown-downloads

문제 해결

  • 인터넷에 연결되어 있는지 확인하세요

  • URL이 유효하고 접근 가능한지 확인하세요

  • 다운로드 디렉토리에 대한 쓰기 권한을 확인하세요

보안

  • 이 도구는 r.jina.ai를 사용하여 마크다운 콘텐츠를 가져옵니다.

  • 로컬 파일은 정리된 파일 이름으로 저장됩니다.

  • 구성 가능한 다운로드 디렉토리로 유연성 제공

기여하다

기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 라이선스 파일을 참조하세요.

부인 성명

이 도구는 있는 그대로 제공됩니다. 다운로드한 콘텐츠의 정확성과 적절성을 항상 검토하세요.

지원하다

문제가 있거나 기능 요청이 있는 경우 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