wb-mcp-server

WB MCP サーバー

AI アシスタントとのチャットから、Wildberries の店舗を運営できます。 Wildberries Seller API をカバーする197個のツールを提供します。商品カード、価格、広告、出荷、レビュー、財務、分析などの機能を Claude、Cursor、Copilot、Gemini CLI、その他あらゆる MCP クライアントから利用できます。1つまたは複数の販売者アカウントを運営し、販売者ポータルをクリックして回るより質問することを好む WB 販売者向けに構築されています（Wildberries はロシア最大のマーケットプレイスです）。

Ozon でも販売していますか？Ozon 向けの同じサーバーもあります。

このサーバーは、約20の WB 販売者アカウントで5か月以上にわたって毎日使用されており、197個のツールを備えています。作者自身が業務で使用しているツールであり、作者の必要に応じて更新されています。詳細はこちら。

You: Which of my product cards are blocked, and why?
You: Show ad cost share for every campaign this week and pause the ones above 15%.
You: Which warehouses currently have an intake coefficient of 0 or 1?
You: Reply to every new 5-star review with a thank-you note.

できること

Wildberries Seller API の分野ごとに分類された197個のツールを利用できます。 各ツールの説明付きの完全な番号付きリストは、docs/tools.md にあります。

同種のサーバーには通常ない、3つの特徴があります。

• 複数ショップ対応。 すべての呼び出しで shop_id を指定するため、1つの会話内で2つの WB 販売者アカウントを利用できます。ショップが1つだけの場合は、shop_id を省略できます。
• WB API の診断。 サーバーが WB のホストに自動で ping を送り、API カテゴリごとに低コストのテストリクエストを1回送信し、トークンの有効期限とスコープをデコードします。また、「機能低下」も強調表示します。これは、以前は動作していたツールが一貫して失敗する状態で、WB が API を変更した確かな兆候です。
• トークンの暗号化。 WB トークンはクライアントの設定ではなく、暗号化（Fernet）して保存されます。

クイックスタート

オプション1：Docker 不要のワンコマンド

このサーバーは stdio を使用します。これは Claude Desktop、Cursor、VS Code などの MCP クライアントが接続する方法です。ビルドは不要です。

uvx wb-mcp-server

または pip 経由でインストールします。

pip install wb-mcp-server
wb-mcp

クライアントの設定（例：claude_desktop_config.json）：

{
  "mcpServers": {
    "wildberries": {
      "command": "uvx",
      "args": ["wb-mcp-server"],
      "env": {
        "WB_API_TOKEN": "your Wildberries API token",
        "DATA_DIR": "~/.wb-mcp"
      }
    }
  }
}

DATA_DIR には、書き込み可能な任意のディレクトリを指定してください。ショップ、キー、統計情報がそこに保存されます。 デフォルトは /data で、Docker 内で使用されるパスです。

オプション 2：ウェブダッシュボードを Docker で利用する

ダッシュボード、WB API の診断、ブラウザーを使ったストア管理が必要な場合は、この方法をお使いください。Docker（Docker Desktop または OrbStack）と Wildberries Seller API トークンが必要です。

git clone https://github.com/DeviceIngineering/wb-mcp-server.git
cd wb-mcp-server
cp .env.example .env          # fine as-is for a local run
docker compose up -d --build

確認します。

curl -s http://localhost:8001/api/health
# {"status":"ok","auth_enabled":false,"health_check_interval_min":30,...}

利用できるようになったもの：

次の手順：

1. http://localhost:8001/shops を開き、Добавить магазин（ストアを追加）を選択して、WB トークンを貼り付け、Проверить（テスト）を選択します。トークンは WB Seller Portal（seller.wildberries.ru）の Настройки → Доступ к API → Создать токен（設定 → API アクセス → トークンを作成）から取得できます。有効期間は 180 日です。残りの有効期間は診断ページに表示されます。
2. MCP クライアントを接続します — 次のセクションをご覧ください。
3. アシスタントに「Wildberries のストアを一覧表示して」と依頼すると、wb_list_shops ツールが実行されます。

起動コマンドの各フラグについて：

docker compose down で停止します（データは wb_data ボリュームに残ります）。 ログ：docker compose logs -f。

git clone https://github.com/DeviceIngineering/wb-mcp-server.git
cd wb-mcp-server
python3 -m venv .venv && source .venv/bin/activate
pip install .
DATA_DIR=./data PORT=8001 python -m wb_mcp.app

クライアントへのインストール

サーバーは SSE 経由で MCP を提供します。GET /sse はイベントストリーム、POST /messages はクライアントのメッセージを受け付けます。SSE のサポート状況はクライアントによって異なるため、それぞれに専用のガイドがあります。ガイドには macOS、Linux、Windows 向けの設定ファイルのパス、貼り付けるだけで使える JSON、認証トークンあり・なしの設定例が記載されています。

docs/ にあるクライアント別ガイドは、現在 ロシア語のみです。ガイド内の設定はファイルパスやフラグを含む完成済みの JSON であり、言語に関係なく読み取れます。

概要と互換性テーブル：docs/README.md。

接続を自動で設定するコマンドがあるクライアントの場合、ガイドではそのコマンドを最初に紹介し、JSON の編集は 2 つ目の選択肢として扱います。最も簡単な設定方法は Claude Code です。

claude mcp add --transport sse wildberries http://localhost:8001/sse
claude mcp list      # expected: wildberries ... ✔ Connected

複数ストアとセキュリティ

複数の販売者アカウント。 ストアは /shops で追加し、それぞれに独自の shop_id が割り当てられます。 wb_list_shops はストアの一覧を返します。197 個あるツールのうち 200 個は、最初の パラメーターとして shop_id を受け取ります（例外は wb_list_shops と wb_degradations です）。 ストアが 1 つだけの場合はパラメーターを省略できます。サーバーが利用可能な唯一のストアを自動的に使います。

重要なのは「2 つのアカウントに対応している」ことではなく、戦略を一度書くだけで、 すべてのアカウントに適用できることです。価格設定ルール、レビュー返信テンプレート、 広告入札の上限を、アカウントを切り替えたり、異なるクライアントの設定に API キーを 分散させたりすることなく、1 つの会話の中ですべてのストアに適用できます。

接続できるアカウント数。 コード上の上限はありません。shops.json は通常の 辞書なので、好きなだけ追加できます。上限を決めるのはこのサーバーではなく Wildberries です。 すべてのアカウントは、サーバーを実行している単一の IP アドレスから WB にアクセスし、 レート制限もアドレスごとにカウントされます。作者自身の見積もりでは、1 つのアドレスあたり 約 20 アカウントなら安全圏です。それ以上の場合は、異なるアドレスを持つ複数のサーバーに分けてください。

見た目以上に重要な理由については、WB の制限を参照してください。 複数のメソッドは毎分 3 リクエストまでで、4XX レスポンスはどれも 10 リクエストとしてカウントされます。 1 つのサーバーで 12 個のアカウントを運用している場合、不正なリクエストが数回続くだけで クォータの消費が 10 倍速くなり、エラーを起こしたストアだけでなく、すべてのストアが同時に制限に達します。

状況を監視する方法があります。

• バックグラウンド診断は、実行ごとにホストごとに /ping を 1 回送信します（制限はホストあたり 30 秒間に 3 リクエストです）。失敗したチェックと警告を履歴に記録します。ブロックされてから気づくのではなく、 制限が近づいていることを事前に把握できます。
• 劣化検出機能は、2 つのケースを見分けます。多くのツールが同時に劣化する場合はアドレス単位の スロットリング、単一のツールが劣化する場合は WB エンドポイントの障害です。 ダッシュボードでは、この違いがひと目でわかります。

トークンの保存場所。 wb_data ボリューム内（コンテナー内の /data）です。

• shops.json — Fernet で暗号化されたトークンを含むストア情報。
• .encryption_key — 初回起動時に生成される暗号化キー。
• stats.db — 呼び出し統計と診断履歴を含む SQLite データベース。

キーは暗号化データの隣に置かれているため、この暗号化は shops.json ファイルだけが 誤って漏えいした場合（バックアップやコピー＆ペースト）の保護にはなりますが、 ボリューム全体にアクセスできる人からは保護できません。データはボリューム全体で移動してください。 DEPLOY.md を参照してください。

MCP の認証。 .env の MCP_AUTH_TOKEN 変数です。

openssl rand -hex 32   # put the value into .env → MCP_AUTH_TOKEN=
docker compose up -d

• 空（デフォルト）の場合 — /sse はポートにネットワークアクセスできるすべての人に公開されます。
• 設定されている場合 — クライアントは URL に Authorization: Bearer <token> または ?token=<token> を含める必要があります。2 つ目の方法は、カスタムヘッダーを送信できないクライアント向けです。

トークンは両方の MCP エンドポイント、GET /sse と POST /messages で検証されます。

このサーバーが行わないこと：

• Web UI（/、/shops、/diagnostics）はトークンで保護されていません。ポートにネットワークアクセスできる すべての人に公開されています。
• ポート 8001 はインターネットに公開することを想定していません。リモートアクセスには Tailscale または VPN を使ってください。
• サーバーは HTTPS を終端しません。外部から TLS 接続する必要がある場合は、手前にリバースプロキシを配置してください。

Web UI：すべての呼び出しを確認できます

一般的な MCP サーバーでは、呼び出しは跡形もなく消えてしまいます。アシスタントが実際に何をしたのか、 どれほど時間がかかったのか、マーケットプレイスがどう応答したのかを確認できず、問題が起きても 何かが失敗するまで気づけません。ここでは、すべての呼び出しに記録があり、すべてのストアに状態があります。 実際の店舗で実際のお金を動かすツールにとって、これは装飾ではなく、信頼を得るための前提条件です。 約 20 アカウントで 5 か月間毎日使われた実績が、これらのページを充実させ、 さらに下にある WB の制限に関するセクションを生み出しました。

ダッシュボード — /

スクリーンショットはこのページの上部にあります。

すべてのツール呼び出しの概要（stats.get_summary()）：

• 呼び出しの合計数、本日の呼び出し数、エラー数、平均呼び出し時間；
• 上位 10 件のツール：呼び出し数、平均時間、エラー数；
• 直近 50 件の呼び出しフィード：タイムスタンプ、ストア、ツール、ミリ秒単位の処理時間、 成功または失敗、エラーテキスト；
• ストアごとのフィルター — 概要の上にある「すべて／特定のアカウント」の切り替え。

ストア — /shops

アカウントは、ファイルを編集したりコンテナを再起動したりせずに、ブラウザー上で直接追加・削除できます。各ストアには Проверить（「テスト」）ボタンがあります。WB に対して低コストの実際のリクエストを 1 回送信し、トークンが有効かどうかをすぐに確認できます。最初の実際の呼び出しで初めて気付くことはありません。トークンはリスト内でマスクされて表示されます（abc***xyz）。

トークンは Fernet で暗号化され、データボリューム内の shops.json に保存されます。キーは隣にある .encryption_key にあります。ストアの保存または削除時には HTTP クライアントプールがリセットされるため、新しいトークンはすぐに有効になります。

診断 — /diagnostics

(スクリーンショットには、作り物のトークンを使ったデモストアが表示されています。WB はすべての ping とプローブに 401 を返すため、ページ全体が赤くなっています。これはチェックに失敗したときの表示です。サーバー自体に問題はありません。有効なトークンを使うと、「Проверка …」の行には ping 13/13, пробы 20/20 と表示され、ストアのステータスは「✅ Здоров」になります。)

ストアごとに、HEALTH_CHECK_INTERVAL_MIN 分ごと（デフォルトは 30 分）にバックグラウンドでチェックを実行します。

• トークン — 有効期限、アクセス可能なカテゴリ、読み取り専用フラグとサンドボックスフラグ；
• 13 個の WB API ホストへの ping — 各ホストの可用性とレイテンシ；
• 20 個のプローブ — API カテゴリごとに、低コストの実際の GET リクエストを 1 回ずつ実行します。WB がエンドポイント名を変更したために「エンドポイントが 404 を返す」といった問題を検出します；
• 平易な表現による警告：「トークンは N 日後に期限切れになります」、 「コンテンツ：/content/v2/... が 404 を返しました — WB が API を変更した可能性があります」；
• 自動ローテーション付きの チェック履歴（直近 1000 件の記録を保持）；
• すべてをすぐに実行する 「今すぐチェック」ボタン。

劣化検出機能

蓄積された統計情報から得られる、最も役立つ機能です。サーバーは、以前は正常に動作していたのに、現在は継続的に失敗しているツールを自動的に検出します。直近 3 回の呼び出しが失敗し、履歴に成功した呼び出しがあるツールが対象です。該当する各ツールについて、最後に成功した呼び出しの時刻、連続エラー数、最新のエラーテキスト、問題が発生した時点を表示します。

つまり、サーバーは独自の統計情報から Wildberries がエンドポイントを停止または無効にしたことを検出し、業務中に問題に遭遇する前に知らせてくれます。制限とエンドポイントの停止日についてのセクションと合わせて、実用的な補完機能となります。このセクションでは WB が発表した内容を一覧にし、こちらでは WB がひそかに実施した変更を検出します。

ダッシュボードで確認するか、チャットから wb_degradations を直接呼び出せます。

外部監視用 JSON

人が見られる情報は、すべて機械でも読み取れます。

そのため、このサーバーを Uptime Kuma、Zabbix、その他の監視システムに組み込むことができ、アシスタントから知らされる前に、無効になったトークンを把握できます。

コンテキスト予算

トークンを消費するものは2つあります。セッションごとに一度読み込まれるツール定義と、呼び出すたびに消費されるツール応答です。どちらも推定ではなく、実際の出品者アカウントで測定しました。scripts/collect_corpus.py は読み取り専用ツールのスナップショットを取得し（ディスクに書き込む前に PII をマスクし、コーパスはリポジトリに含めません）、scripts/measure_corpus.py がそのコストを報告します。

定義。 ストアを1つだけ設定した場合、197個のツールで 17 700トークンを消費し、27 460から削減されます。説明はそれぞれ1文です。ストアが1つだけの場合は、スキーマから shop_id が除外されます（サーバーが自動で補完します）。また、空のスキーマフィールドはシリアライズされません。

応答。 実際の問題は、少数の巨大なペイロードにありました。

サーバー側では、次のように対応しています。

• view: compact | full。 重量の大きいツールは、呼び出し時に指定されたフィールドを返します。view="full" を指定すると、生の API 応答が返されます。非表示にしたフィールドは応答自体に記載されるため、モデルは何を要求できるか把握できます。
• 切り捨ての通知。 limit と同じ件数のレコードが返された場合、応答にデータが一部のみであることを示す警告が付加されます。これがないと、モデルは一部分を全カタログとして扱い、推論してしまいます。
• サイズ制限。 クライアントの出力上限（Claude Code ではデフォルトで 25 000 の MAX_MCP_OUTPUT_TOKENS）に収まらない応答は、サーバー側で切り詰め、全件数と省略したレコード数を示します。受信時に黙って切り詰められることはありません。
• API にないサーバー側フィルター。 WB は手数料の参照データを全件返しますが、ここでは subject パラメーターで絞り込めます。

注記は、JSON 内のフィールドではなく、独立したコンテンツブロックとして届きます。WB のエンドポイントの半数はトップレベルに配列を返すため、ラップするとデータへのすべてのパスが壊れてしまいます。

ツールプロファイル。 ツール検索に対応していないクライアントでは、リクエストのたびにカタログ全体のトークンが必要になります。WB_TOOLSETS を使うと、使用するプロファイルだけを残せます。プロファイルは WB のドキュメントのセクションではなく、実際の作業に沿って分けています。たとえば、プロモーションの監査にはプロモーション、価格、価格の隔離をまとめて使うためです。

core プロファイル（ストア、診断、機能低下、トークン情報）は常に有効です。問題が発生したときこそ、診断が必要だからです。無効なプロファイルは wb_list_shops の説明に記載され、無効なツールを呼び出すと、そのツールが属するプロファイルが返されます。そのため、アシスタントは「できません」と言うのではなく、理由を説明できます。

Claude Code では、これらは不要です。デフォルトでツール検索が有効になっており、必要に応じてスキーマを読み込みます。Cursor、Cline、Continue、Claude Desktop は tools/list をすべて取得するため、プロファイルはこれらのクライアント向けです。

設計上の判断

• 汎用的なツールを少数用意するのではなく、対象を絞ったツールを202個用意します。 これらをaction形式のエンドポイントにまとめれば定義トークンを節約できますが、障害の性質が変わります。「そのようなツールはない」ではなく、副作用を伴う誤った呼び出しが発生します。また、これらのツールの中には価格を設定したり、広告キャンペーンを開始したりするものもあります。
• if文の連鎖ではなく、辞書でディスパッチします。 NO_CLIENT_DISPATCH、CLIENT_DISPATCH、SHOP_DISPATCHで名前とハンドラーを対応付け、すべてのツールにハンドラーがあり、孤立したハンドラーがないことをテストで検証します。ツールが197個もあると、if文の連鎖は気付かないうちに劣化します。
• サーバー自身が問題を診断します。 wb_diagnosticsはすべてのWBホストにpingを送信し、各APIカテゴリで軽量な実リクエストを実行します。wb_degradationsは、以前は動作していたのに、現在は継続的に失敗しているツールを報告します。マーケットプレイスのAPIは予告なく変更されます。「自分のトークンに問題があるのか、それともWBがエンドポイントを変更したのか」という疑問に、1回の呼び出しで答えられる必要があります。
• 負荷の高いツールではcompactがデフォルトです。 コーパスから、非表示のフィールドは写真URL、プロモーション履歴、倉庫の営業時間であり、意思決定の基になるデータではないことが分かりました。レスポンスには何を非表示にしたかが示されるため、情報が黙って失われることはありません。
• 店舗が1つの場合、スキーマからshop_idがなくなります。 200個のスキーマで同じパラメータブロックを繰り返すと、情報がないままセッションごとに3 400トークンを消費していました。サーバーは唯一の店舗を使用し、2つ目の店舗が追加されるとすぐにパラメータを戻します。
• mcp<2に意図的に固定しています。 2.0の低レベルAPIでは、このサーバーの基盤となっているデコレーターハンドラーが削除されています。移行は別タスクとし、実行時に初めて判明するのではなく、固定箇所にその理由を記載しています。
• トークンは保存時に暗号化され（Fernet、鍵はデータボリューム内）、UIではマスキングされます。コーパス収集ツールはファイルに書き込む前に個人データをマスキングします。注文やチャットのペイロードには、顧客の氏名、電話番号、住所が含まれるためです。

仕組み

FastAPI アプリケーションを実行する 1 つの Docker コンテナが、MCP サーバー（SSE 経由）と小規模な Web UI の 2 つの役割を同時に担います。ファイルごとの説明は次のとおりです。

• wb_mcp/server.py — MCP サーバー本体です。202 個の Tool オブジェクトからなる TOOLS リスト（名前、説明、引数の JSON スキーマ）は、tools/list への応答としてクライアントが受け取るものと完全に一致します。呼び出しは 3 つの辞書で振り分けられます。NO_CLIENT_DISPATCH（WB へのアクセス不要）、CLIENT_DISPATCH（ストアの HTTP クライアントが必要）、SHOP_DISPATCH（さらに shop_id が必要）です。stdio のみをサポートするクライアント向けの stdio エントリーポイント main() もここにあります。
• wb_mcp/client.py — Wildberries の 14 のホストに対応する HTTP クライアントです。各ストアに 1 つの WBClient を用意し、トークンを含む httpx.AsyncClient でラップします。クライアントは shop_id をキーとするプールにキャッシュされます。
• wb_mcp/app.py — FastAPI です。MCP 用の GET /sse と POST /messages、ダッシュボード、ストアと診断のページ、/api/* JSON API、MCP_AUTH_TOKEN の確認、バックグラウンドのヘルスチェックループが含まれます。
• wb_mcp/settings.py — ストアとキーを扱います。shops.json の読み書き、Fernet による暗号化、旧形式の単一ストア settings.json からの移行、UI でのトークンのマスキングを行います。フォールバックとして、WB_API_TOKEN が設定されている場合は default という名前のストアが表示されます。
• wb_mcp/diagnostics.py — WB ホストへの ping、JWT トークンのデコード（有効期限、スコープ、サンドボックスフラグ）、「プローブ」（API カテゴリごとに 1 回ずつ行う低コストの実リクエスト）、WB のニュースを扱います。
• wb_mcp/stats.py — aiosqlite 経由の SQLite です。すべてのツール呼び出しについて、所要時間、成功フラグ、shop_id を記録します。この記録は劣化検出とヘルスチェック履歴に使われます。
• wb_mcp/templates/ — PicoCSS を使った 3 つのページです。フロントエンドのビルド手順はありません。

注意が必要な点：

• ストアが 1 つだけの場合、shop_id は自動的に補完されます。 日常的には便利ですが、2 つ目のアカウントを追加すると、shop_id を指定しない呼び出しは「Укажите shop_id」（「shop_id を指定してください」）を返すようになります。
• 失敗も含め、すべての呼び出しが統計に記録されます。 これが劣化検出を可能にします。「以前は動作していたが、今は継続的に失敗する」という状況は、WB が API を変更したことを示すシグナルであり、操作ミスを示すものではありません。wb_degradations またはダッシュボードを確認してください。
• 30 分ごとのバックグラウンド診断では、WB に実際にリクエストを送信し、レート制限を消費します。 これが支障になる場合は、.env で HEALTH_CHECK_INTERVAL_MIN=0 を設定してください。
• レスポンスはそのまま返されます。 WB からの生の JSON を再構成せずに返します。そのためツールの動作は予測しやすくなりますが、大量のレポートを取得するとコンテキストウィンドウを使い切るため、フィルターを指定してリクエストしてください。
• POST /messages は通常の FastAPI ルートではなく、独立した ASGI アプリとして Mount されています。 handle_post_message は ASGI レスポンスを自ら送信します。ルート内ではフレームワークがレスポンスをもう一度送信してしまい、すべての POST で接続が切断されます。そのため、このエンドポイントの認証はアプリ内で手動で確認しています。
• mcp ライブラリのバージョンは >=1.0.0,<2 に固定されています。 このサーバーは、mcp 2.0 で削除された mcp 1.x のデコレーター API（@app.list_tools()）を前提に作られています。pyproject.toml の上限を解除しないでください。mcp 2.x では、サーバーの起動時に AttributeError: 'Server' object has no attribute 'list_tools' が発生します。

環境変数

Wildberries API の制限

これらはこのサーバーではなく、WB 自体の制限です。ただし、アシスタントは頻繁に制限に達するため、あらかじめ把握しておくとよいでしょう。この一覧はドキュメントからの転載ではなく、約 20 アカウントで 5 か月間にわたって毎日 API を呼び出した経験と、診断ログに基づいています。

• GET /adv/v3/fullstats（広告統計）— 1 分あたり 3 リクエスト、期間は 31 日以内です。
• 売上ファネル v3 — 1 分あたり 3 リクエストです。日ごとの履歴を取得できるのは最大で直近 1 週間です。
• /ping — ホストごとに 30 秒あたり 3 回です（バックグラウンド診断でもこの制限を考慮しています）。
• すべての 4XX レスポンスは、制限に対して 10 リクエストとしてカウントされます（2026-06-04 以降適用されているルールです）。ループ内でパラメーターを 1 つ間違えるだけで、レート制限に達します。
• reportDetailByPeriod は 2026-07-15 に Wildberries によって削除されました。サーバーは finance-api を呼び出します。古いエンドポイントへのフォールバックは、すでに廃止されているため削除されています。販売レポートにはトークンの Finance カテゴリが必要です。これがない場合、何を再発行すればよいかを明示するエラーが表示され、内容の分からない拒否にはなりません。
• FBW の供給は API 経由では作成できず、セラーポータルからのみ作成できます。wb_fbw_* ツールは情報提供用です。
• WB トークンの有効期間は 180 日です。残りの有効期間は wb_token_info と /diagnostics ページで確認できます。
• WB からの 429 は失敗ではなく、レート制限を意味します。1 分後に再試行してください。

2026 年 8 月、dev.wildberries.ru のドキュメントと照合して確認済みです。

技術リファレンス

Wildberries Seller API のホスト

診断

• /diagnostics ページ — ストアごとのトークンの有効期限とスコープ、すべての WB API ホストへの ping、カテゴリ別のプローブ、チェック履歴、「今すぐチェック」ボタンを表示します。
• HEALTH_CHECK_INTERVAL_MIN 分ごとにバックグラウンドで自動チェックを実行します。
• 劣化検出機能 — 動作しなくなったツールをダッシュボード上で強調表示します。
• MCP ツール：wb_diagnostics、wb_token_info、wb_degradations、wb_api_news。
• GET /api/health — 外部監視用の JSON サマリーを返します。
• POST /api/diagnostics/run — すべてのストアのチェックを今すぐ実行します。
• GET /api/diagnostics/<shop_id> — 単一ストアの詳細な診断情報を返します。

プロジェクトの構成

wb-mcp-server/
├── docker-compose.yml          # port 8001, wb_data volume
├── Dockerfile                  # python:3.12-slim
├── pyproject.toml
├── DEPLOY.md                   # deploying to a dedicated machine, moving the data
├── docs/                       # client setup guides + tool reference
└── wb_mcp/
    ├── server.py       # MCP server: 197 tools, dispatch tables, stdio mode
    ├── client.py       # HTTP clients for the 14 Wildberries APIs
    ├── app.py          # FastAPI: SSE + web UI + auth + health loop
    ├── diagnostics.py  # pings, JWT decoder, probes, API news
    ├── settings.py     # stores and keys (Fernet)
    ├── stats.py        # call statistics and check history (SQLite)
    └── templates/      # PicoCSS: dashboard, diagnostics, shops

デプロイ

サーバーを専用マシンに移動する手順、ストアの移行、自動起動の設定については、DEPLOY.md（ロシア語）をご覧ください。

Ozon 向けの同じサーバー

DeviceIngineering/ozon-mcp-server は、もう一方のマーケットプレイス（Ozon はロシアのもう一つの大手マーケットプレイス）向けの同じツールです。 同じアーキテクチャ、ダッシュボードと診断機能を備えた同じウェブ UI、shop_id による同じ複数ストア対応、 同じ SSE トランスポート、同じクライアント接続方法を採用しています。一方をセットアップすれば、 もう一方も同じ手順で利用できます。異なるのはポートとツールセットだけです。

1 台のマシンで同時に実行できます。ポートも Docker ボリュームも異なるため、競合しません。

同じサーバー上で動作していても、レート制限には影響しません。どちらも同じ IP 経由で接続しますが、 Wildberries と Ozon はそれぞれ別のプラットフォームであり、制限も個別にカウントされます。 複数ストアのセクションで説明した、アドレスごとのアカウント数の上限は、各プラットフォーム内で個別に適用されます。

API アクセスから実用的な価格改定ツールへ

このサーバーは、モデルが販売者アカウントにアクセスできるようにします。価格を いくらにすべきかを決めるのは別の役割であり、ozon-wildberries-repricer が担います。このツールは基準価格を保持し、各マーケットプレイスの実際の手数料から損益分岐点となる下限価格を算出し、 原価を下回る価格になるプロモーションから商品を除外し、実際の販売状況で制御された実験を行って、 よりよい価格を探すこともできます。

Ozon、Wildberries、Yandex Market を一か所で扱えます。また、LLM エージェント向けの独自の HTTP 制御プレーンを備え、モデルに必要な安全策も用意しています。Wildberries の隔離措置を引き起こすような価格変更は 複数回に分けて実施され、マーケットプレイスが実際には行っていない変更を成功と報告する場合があるため、 価格は 3 分後に再取得されます。また、複数のエージェントが同じ商品カタログを扱っても、 互いの判断を上書きできません。

マーケットプレイスのアカウントがなくても実行できます。npm run demo を実行すると、 合成商品カタログを用意してアプリを起動します。

更新とサポート

Wildberries は API を絶えず変更しています。エンドポイントの追加、名称変更、廃止が行われており、 上記の制限事項のセクションでは、実際に確認された内容をまとめています。 このサーバーは作者が日常的に使用しているツールで、約 20 の販売者アカウントで 5 か月以上にわたって毎日利用しています。 更新は作者が必要としたときに行われます。自分のストアで次の変更による不具合が発生した際に対応するものであり、 定期的な更新ではありません。そのため、コミットの間隔が長くなることがあります。これは、その間に WB が何も壊していないということです。 対応時期についての確約はありません。

修正を急ぎで必要とする場合は、[email protected] までご連絡ください。 Issue とプルリクエストは歓迎しており、確認しています。

バージョン履歴：CHANGELOG.md。

ライセンス

MIT — 詳細は LICENSE をご覧ください。

MCP Registry

公式の MCP Registry に公開されています：

mcp-name: io.github.DeviceIngineering/wb-mcp-server