Skip to main content
Glama
deenesjakoruzh
dazeb

Markdown Downloader

by dazeb
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

Servidor MCP del descargador de Markdown

insignia de herrería

Descripción general

Markdown Downloader es un potente servidor MCP (Protocolo de Contexto de Modelo) que permite descargar páginas web como archivos Markdown fácilmente. Aprovechando el servicio r.jina.ai, esta herramienta ofrece una forma sencilla de convertir contenido web a formato Markdown.

Related MCP server: crawl-mcp-server

Características

  • 🌐 Descarga páginas web en formato Markdown usando r.jina.ai

  • 📁 Directorio de descargas configurable

  • 📝 Genera automáticamente nombres de archivos con fecha.

  • 🔍 Lista de archivos Markdown descargados

  • 💾 Configuración persistente

Prerrequisitos

  • Node.js (versión 16 o superior)

  • npm (Administrador de paquetes de Node)

Instalación

Instalación mediante herrería

Para instalar Markdown Downloader para Claude Desktop automáticamente a través de Smithery :

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

Instalación manual

  1. Clonar el repositorio:

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

  2. Instalar dependencias:

    npm install

  3. Construir el proyecto:

    npm run build

Agregar manualmente el servidor al archivo de configuración MCP de Cline/Roo-Cline

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"
      ]
    }
  }
}

Ventanas

{
  "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"
      ]
    }
  }
}

Herramientas y uso

1. Establecer directorio de descarga

Cambiar el directorio de descarga:

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

  • Valida que el directorio exista y se pueda escribir.

  • Conserva la configuración para uso futuro

2. Descargar Markdown

Descargar una página web como archivo markdown:

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

  • La URL se antepondrá con r.jina.ai

  • Formato del nombre de archivo: {sanitized-url}-{date}.md

  • Guardado en el directorio de descarga configurado

3. Lista de archivos descargados

Lista de todos los archivos Markdown descargados:

use list_downloaded_files

4. Obtener directorio de descargas

Recuperar el directorio de descarga actual:

use get_download_directory

Configuración

Linux/macOS

  • La configuración se almacena en ~/.config/markdown-downloader/config.json

  • Directorio de descarga predeterminado: ~/.markdown-downloads

Ventanas

  • La configuración se almacena en %APPDATA%\markdown-downloader\config.json

  • Directorio de descarga predeterminado: %USERPROFILE%\Documents\markdown-downloads

Solución de problemas

  • Asegúrese de tener una conexión a Internet activa

  • Compruebe que la URL sea válida y accesible

  • Verificar los permisos de escritura para el directorio de descarga

Seguridad

  • La herramienta utiliza r.jina.ai para obtener contenido rebajado

  • Los archivos locales se guardan con nombres de archivo desinfectados

  • El directorio de descarga configurable permite flexibilidad

Contribuyendo

¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.

Licencia

Este proyecto está licenciado bajo la Licencia MIT. Consulte el archivo de LICENCIA para más detalles.

Descargo de responsabilidad

Esta herramienta se proporciona tal cual. Revise siempre el contenido descargado para comprobar su precisión e idoneidad.

Apoyo

Para problemas o solicitudes de funciones, abra un problema en el repositorio de 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