Skip to main content
Glama
angrysky56

MCP Windows Website Downloader Server

by angrysky56

MCP ウェブサイト ダウンローダー

ドキュメント Web サイトをダウンロードし、RAG インデックス作成用に準備するためのシンプルな MCP サーバー。

特徴

  • 完全なドキュメント サイトをダウンロードします (とにかく大きな塊です)。

  • リンク構造とナビゲーションは維持されますが、実際はそうではありません。笑

  • アセット (CSS、JS、画像) をダウンロードして整理しますが、実際には AI フレンドリーではないため、おそらくすべてを何らかの解析またはベクトル化して DB などに格納する必要があります。

  • RAG システムのクリーンなインデックスを作成します。現在は各フォルダーにインデックスを作成しているようですが、確認もされていません。

  • シンプルな単一目的の MCP インターフェースです。

Related MCP server: Skrape MCP Server

インストール

フォークしてダウンロードし、リポジトリに cd します。

uv venv
./venv/Scripts/activate
pip install -e .

独自のパスを使用して、これを claude_desktop_config.json に追加します。

   "mcp-windows-website-downloader": {
     "command": "uv",
     "args": [
       "--directory",
       "F:/GithubRepos/mcp-windows-website-downloader",
       "run",
       "mcp-windows-website-downloader",
       "--library",
       "F:/GithubRepos/mcp-windows-website-downloader/website_library"
     ]
   },

代替テキスト

心配する必要のない他の使用法は、幻覚的である可能性があります(笑)

  1. サーバーを起動します。

python -m mcp_windows_website_downloader.server --library docs_library
  1. Claude Desktop またはその他の MCP クライアントを通じて使用:

result = await server.call_tool("download", {
    "url": "https://docs.example.com"
})

出力構造

docs_library/
  domain_name/
    index.html
    about.html
    docs/
      getting-started.html
      ...
    assets/
      css/
      js/
      images/
      fonts/
    rag_index.json

発達

サーバーは標準の MCP アーキテクチャに従います。

src/
  mcp_windows_website_downloader/
    __init__.py
    server.py    # MCP server implementation
    core.py      # Core downloader functionality
    utils.py     # Helper utilities

コンポーネント

  • server.py : ツールの登録とリクエストを処理するメインの MCP サーバー実装

  • core.py : 適切なアセット処理を備えたコアウェブサイトダウンロード機能

  • utils.py : ファイル処理と URL 処理のためのヘルパーユーティリティ

設計原則

  1. 単一責任

    • 各モジュールには明確な目的がある

    • サーバーはMCPインターフェースを処理する

    • コアはダウンロードを処理する

    • Utilsは一般的な操作を処理します

  2. クリーンな構造

    • 元のサイト構造を維持

    • 資産を種類別に整理する

    • RAGシステムの明確なインデックスを作成します

  3. 堅牢な操作

    • 適切なエラー処理

    • 適切な水深制限

    • アセットダウンロードの検証

    • クリーンなURL/パス処理

RAGインデックス

rag_index.jsonファイルには次の内容が含まれます。

{
  "url": "https://docs.example.com",
  "domain": "docs.example.com", 
  "pages": 42,
  "path": "/path/to/site"
}

貢献

  1. リポジトリをフォークする

  2. 機能ブランチを作成する

  3. 変更を加える

  4. プルリクエストを送信する

ライセンス

MITライセンス - LICENSEファイルを参照

エラー処理

サーバーは一般的な問題を処理します:

  • 無効なURL

  • ネットワークエラー

  • アセットのダウンロード失敗

  • 不正なHTML

  • 深い再帰

  • ファイルシステムエラー

エラー応答は次の形式に従います。

{
  "status": "error",
  "error": "Detailed error message"
}

成功応答:

{
  "status": "success",
  "path": "/path/to/downloaded/site",
  "pages": 42
}

Available Tools

1 tool
downloadC

Download documentation website for RAG indexing

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesDocumentation site URL

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 full burden for behavioral disclosure. It mentions downloading for RAG indexing, implying a read operation, but doesn't specify what gets downloaded (e.g., files, content), permissions needed, rate limits, or output format. This leaves significant behavioral gaps.

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 no wasted words, clearly front-loading the core action and purpose. It's appropriately sized for a simple tool.

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 no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It lacks details on what the download produces (e.g., files, structured data), how it handles errors, or any behavioral traits, making it inadequate for a tool that performs an operation like downloading.

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%, so the schema already documents the single parameter 'url' as 'Documentation site URL'. The description adds no additional parameter details beyond what the schema provides, meeting the baseline of 3 when schema does the heavy lifting.

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') and the target ('documentation website for RAG indexing'), making the purpose understandable. It doesn't need to distinguish from siblings since none exist, so a 4 is appropriate for clear but not maximally specific purpose.

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, prerequisites, or constraints. It simply states what it does without context for usage decisions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • First observeddownload

TDQS

B3.1/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap between tools. The single tool has a clear and distinct purpose.

Naming Consistency5/5

A single tool inherently has perfect naming consistency, as there are no other tools to compare it against for patterns or conventions.

Tool Count2/5

One tool is too few for a server named 'MCP Windows Website Downloader Server', which suggests a scope that might include operations like listing available websites, configuring downloads, or managing downloaded content. A single download tool feels thin and incomplete for this domain.

Completeness2/5

The tool surface is severely incomplete for the implied domain of downloading Windows documentation websites. It lacks essential operations such as listing available websites, checking download status, managing or deleting downloaded content, or configuring download parameters, which are likely needed for effective RAG indexing workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    This server converts webpages into clean, structured Markdown optimized for language model consumption, removing unnecessary content and supporting JavaScript rendering.
    1
    12
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A locally-hosted MCP server that provides AI assistants with advanced web crawling capabilities, including structured data extraction, deep site crawling, and page screenshots. It enables users to convert single or multiple URLs into clean Markdown content for processing by LLMs without requiring external API keys for basic features.
    -