ozon-mcp-server

Ozon MCP サーバー

AI アシスタントとのチャットから、Ozon のストアを直接運営できます。価格、プロモーション、 広告、注文、返品、レビュー、財務など、Ozon Seller API と Performance API を通じて 156 個のツールを利用できます（Ozon はロシア最大のマーケットプレイスです。Seller API はカタログと業務を、Performance API は有料広告を扱います）。 複数のストアを運営する販売者向けに開発されており、呼び出しごとに shop_id を指定します。 API キーは自分のサーバー上で暗号化され、外部に持ち出されることはありません。 ほかの Ozon MCP サーバーとの違いは、Seller API だけでなく広告にも対応していること、 そして組み込みの診断機能により、アシスタントが遭遇する前に問題のある Ozon エンドポイントを 特定できることです。

Wildberries でも販売していますか？WB 向けの同じサーバーもあります — wb-mcp-server。

これは作者自身が実際に使用しているツールです。5 か月以上にわたって毎日使い、 約 20 の販売者アカウントと 156 個のツールに対応しています。作者に必要なときに更新されます。 それがあなたにとって何を意味するかについては、アップデートとサポートをご覧ください。

docs/ にあるクライアント別のインストールガイドは、現在ロシア語のみです。 記載されている設定は、そのまま貼り付けて使える JSON なので、言語に関係なく同じように読めます。 ファイルパス、URL http://localhost:8000/sse、ヘッダー Authorization: Bearer <MCP_AUTH_TOKEN> が含まれています。

You: Which of my products is Ozon planning to pull into a promo?
You: Show ad campaign spend for the week and stop the ones burning money.
You: Which products have a worse price index than their competitors?
You: Reply with a thank-you to every new 5-star review.

できること

グループ	ツール	内容
プロモーションと割引	14	Ozon のプロモーション（一覧、候補、参加・退出）、セラー独自のプロモーション、「割引してほしい」という購入者からのリクエスト
価格と価格戦略	14	価格と最低価格の設定、価格指数、最低価格タイマー、競合を追跡する自動戦略
広告（Performance API）	22	「Trafarety」CPC キャンペーン（Ozon のスポンサー掲載フォーマット）、入札額と予算、「注文ごとの支払い」（CPO）、商品別および日別の統計
商品	21	出品情報と商品カード、属性、在庫、インポートと一括更新、メディア、アーカイブ、証明書
FBS・FBO 注文	17	未処理の注文、梱包（v4）、ラベル、キャンセル、引き渡し証明書、原産国
返品とキャンセル	10	FBO と FBS を統合した返品一覧、セラーの判断が必要な rFBS の申し立て、キャンセルリクエスト
レビュー、質問、チャット	13	レビューと返信、購入者からの質問、チャットでのやり取り（v3）
倉庫とレポート	8	FBS 倉庫、配送方法、レポートの生成とダウンロード
財務	7	残高、取引、計上額、販売実績レポート、相互決済、キャッシュフロー
カテゴリー、ブランド、証明書	7	カテゴリーツリー、属性とその許可値、証明書
分析	5	SKU 分析、在庫と回転率、Ozon 検索での商品掲載順位、検索クエリの上位
FBO 納品	4	納品注文（v3）、カウンター、時間枠
評価	2	現在のセラー評価とその履歴
診断	2	Ozon API の利用可能状況のセルフチェック、機能低下の検出
通知	2	プッシュ Webhook サブスクリプションとイベントタイプのリファレンス
企業情報	2	セラー情報と料金プラン
ストア	1	接続済みストアの一覧とその shop_id

FBO と FBS は Ozon のフルフィルメントモデルです。FBO では Ozon の倉庫から発送し、 FBS では自社から発送します。rFBS は独自の配送を行う FBS です。

すべてのツールの番号付き一覧、説明、パラメーターは docs/tools.md にあります。これは ozon_mcp/server.py の TOOLS 定数から生成されます。すべての MCP クライアントに返される tools/list と同じ内容です。

クイックスタート

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

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

uvx ozon-mcp-server

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

pip install ozon-mcp-server
ozon-mcp

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

{
  "mcpServers": {
    "ozon": {
      "command": "uvx",
      "args": ["ozon-mcp-server"],
      "env": {
        "OZON_CLIENT_ID": "your Client-Id",
        "OZON_API_KEY": "your API key",
        "DATA_DIR": "~/.ozon-mcp"
      }
    }
  }
}

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

オプション 2：Web ダッシュボード付き Docker

ダッシュボード、Ozon API の診断、ブラウザーを使ったストア管理が必要な場合は、こちらを使用してください。5 つのコマンドを実行します。

git clone https://github.com/DeviceIngineering/ozon-mcp-server.git
cd ozon-mcp-server
cp .env.example .env               # fine as-is for a trusted local network
docker compose up -d --build       # builds the image, serves on port 8000
open http://localhost:8000/shops   # add a store and its Ozon API keys

各手順の内容：

• .env — すべての変数は省略可能です。ストアキーは、ここで設定するより Web UI から入力するほうが簡単です。事前に設定しておく価値があるのは、サーバーにあなた以外もアクセスできる場合の MCP_AUTH_TOKEN です（openssl rand -hex 32 で生成できます）。
• docker compose up -d --build — Dockerfile からイメージをビルドし、ポート 8000:8000 を割り当て、ストア、キー、呼び出し統計、診断履歴を保存する ozon_data ボリュームを作成します。restart: unless-stopped により、再起動後にコンテナーが再び起動します。
• /shops — ストアの追加フォームです。shop_id（チャットで使用する識別子）、表示名、Seller API 用の Client-Id と Api-Key、Performance API 用の Client-Id と Client-Secret を入力します。「Проверить」（テスト）ボタンを押すと、Ozon にリアルタイムでリクエストを送信し、キーが受け付けられたかどうかを確認できます。

起動後は、以下のアドレスを使用できます。

アドレス	内容
http://localhost:8000/	ダッシュボード：呼び出し回数、エラー、縮退
http://localhost:8000/shops	ストアとキー
http://localhost:8000/diagnostics	Ozon API の診断
http://localhost:8000/api/health	ヘルスエンドポイント、JSON
http://localhost:8000/sse	MCP エンドポイント — クライアントの接続先です

Web UI はロシア語です。

停止するには、docker compose down を実行します（データは ozon_data ボリュームに保持されます）。 ログを確認するには、docker compose logs -f を実行します。

Docker を使わない場合

python3 -m venv .venv && source .venv/bin/activate
pip install .
DATA_DIR=./data PORT=8000 ozon-mcp-web

DATA_DIR のデフォルトは /data です。ローカルで実行する場合は、書き込み可能なディレクトリを必ず指定してください。

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

トランスポートは http://<host>:8000/sse の SSE です。クライアントによって SSE のサポート状況は異なります。直接対応するものもあれば、mcp-remote ブリッジが必要なものもあります。クライアントごとに、macOS、Linux、Windows 用の設定パスと、すぐに使える JSON を記載したガイドがあります。ガイドはロシア語ですが、JSON ブロックは言語に依存しません。

クライアント	SSE に直接対応	ガイド
Claude Code	はい	docs/install-claude-code.md
Claude Desktop	いいえ、mcp-remote ブリッジが必要	docs/install-claude-desktop.md
Cursor	はい	docs/install-cursor.md
Windsurf / Devin Desktop	はい	docs/install-windsurf.md
VS Code (GitHub Copilot)	はい	docs/install-vscode-copilot.md
Cline	はい	docs/install-cline.md
Continue.dev	はい	docs/install-continue.md
Zed	未確認、ブリッジを推奨	docs/install-zed.md
JetBrains AI Assistant / Junie	はい	docs/install-jetbrains.md
Gemini CLI	はい	docs/install-gemini-cli.md
OpenAI Codex CLI	いいえ、mcp-remote ブリッジが必要	docs/install-codex.md

最短の例として、Claude Code の場合：

claude mcp add --transport sse ozon http://localhost:8000/sse \
  --header "Authorization: Bearer <MCP_AUTH_TOKEN>"

クライアントの概要とブリッジの説明については、docs/README.md を参照してください。

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

ストアはウェブ UI で追加し、すべてのツールで必須の shop_id を指定します。 ozon_list_shops を使うと、登録されているストアを確認できます。チャットでは 「ストア alpha の在庫を表示して」のように指示します。

真の利点は切り替えそのものではなく、戦略を一度だけ記述して、すべてのアカウントに展開できることです。価格、レビューへの返信、広告入札に関するルールを、すべてのストアに一度に適用できます。セラーアカウントへのログインとログアウトを繰り返したり、クライアント設定間でキーをコピーしたりする必要はありません。

その代わり、IP アドレスを共有することになります。すべてのアカウントは、MCP を実行するサーバーの同じアドレスから Ozon に接続します。Ozon のレート制限は、ほかの条件とともにアドレス単位でカウントされます。そのため、アカウント数が増え、戦略による負荷が高くなるほど、合計トラフィックがスロットリングやブロックが発生するしきい値に近づきます。

• コード上、ストア数に制限はありません。
• 実際の上限は、このサーバーではなく Ozon の IP 単位の制限によって決まります。
• 作者自身の推定では、アカウントが約 20 個であれば、トラフィックはまだ安全な範囲に収まります。
• それを超える場合は、ストアをアドレスの異なる複数のサーバーに分散してください。

上限が近づいているかどうかは確認できます。その場所はウェブ UI です。ping の失敗や診断の警告が増え始め、呼び出し統計のエラー率が跳ね上がります。ダッシュボードでは 2 つのケースも見分けられます。大規模なスロットリングでは多数のツールが同時に劣化し、エンドポイントの障害では 1 つのツールだけに問題が発生します。

キーの保存方法：

• 初回使用時に、Fernet キーである .encryption_key が DATA_DIR に作成されます。
• ストアのキーはこのキーで暗号化され、DATA_DIR/shops.json に保存されます。
• ウェブ UI ではキーはマスク表示され（abc***xyz）、マスクされた値を保存しても実際のキーは上書きされません。
• Docker では、これらすべてが ozon_data ボリュームに保存されます。別のマシンに移行するには、ボリューム全体をコピーしてください。そうしないと暗号化キーを失います （DEPLOY.md、ロシア語）。

アクセスに関する注意事項：

• MCP_AUTH_TOKEN が保護するのは /sse のみです。Authorization: Bearer … ヘッダー、または ?token=… クエリパラメーターとして渡してください。
• MCP_AUTH_TOKEN が空の場合、認証は一切行われません。信頼できるネットワーク上でのみ許容されます。
• ウェブ UI（/、/shops、/diagnostics）と /api/* はトークンで保護されていません。ポートにアクセスできる人なら誰でもダッシュボードを見て、ストアを追加できます。
• ポート 8000 をインターネットに直接公開しないでください。リモートアクセスには Tailscale または VPN を使用してください。
• サーバーは HTTPS を終端しません。外部からの TLS 接続が必要な場合は、前段にリバースプロキシを配置してください。

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

一般的な MCP サーバーでは、呼び出しの記録は見えなくなります。アシスタントが何かを実行しても、何をしたのか、どれくらい時間がかかったのか、どんなエラーが発生したのかを把握できるのはアシスタントだけです。ここでは、呼び出しごとにログに 1 行が記録され、問題のあるツールにはダッシュボード上にマーカーが表示されます。ストアで実際のお金を動かすツールにとって、これは単なる飾りではなく、信頼して使うための条件です。

呼び出し統計とチェック履歴は架空のものではありません。約 20 のセラーアカウントで 5 か月以上にわたって日々使用した結果です。制限事項のセクションにある、検出された Ozon API の変更一覧も同じ情報源に基づいています。ドキュメントからコピーしたのではなく、劣化ログから読み取ったものです。

ダッシュボード /

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

• 上部の 4 つのカウンター：呼び出し総数、本日の呼び出し数、エラー数、平均呼び出し時間（ミリ秒）。
• 上位 10 個のツール：呼び出し数、平均所要時間、失敗した呼び出し数。
• 直近 50 件の呼び出しの一覧：タイムスタンプ、shop_id、ツール名、所要時間、成功または失敗、エラーテキスト。
• ストアごとのフィルター（/?shop=alpha）：単一アカウントの同じ統計情報を表示します。
• 上部に 2 つのバナーが表示されます。劣化しているツールと、「直近の Ozon API チェックで問題が見つかりました」という通知です。

ストア /shops

アカウントはブラウザー上で直接追加・削除でき、ファイルを編集したり、コンテナーを再起動したりする必要はありません。「Проверить」（テスト）ボタンを押すと、両方の API に対してリアルタイムでリクエストを送信します（POST /api/shops/{shop_id}/test）。そのため、タスクの途中で初めて実際に呼び出すときではなく、アカウントを追加した時点でキーを検証できます。トークンは Fernet で暗号化され、暗号化キーは DATA_DIR/.encryption_key に保存されます。UI ではキーがマスクされます。

診断 /diagnostics

(スクリーンショットには、意図的に無効なキーを設定したデモストアが表示されています。そのため、すべてのプローブが赤くなっています)

• ストアごとに、キーの設定状況、Ozon ホストの稼働状況、Seller API の 12 カテゴリのプローブ、Performance API キーのチェックを確認できます。
• HEALTH_CHECK_INTERVAL_MIN 分ごとにバックグラウンドチェックを実行します（デフォルトは 30 分、0 で無効）。また、「Проверить сейчас」（今すぐチェック）ボタンを使えば、すぐにチェックを実行できます（POST /api/diagnostics/run）。
• チェック履歴には、時刻、ストア、ステータス、失敗した ping の数、失敗したプローブの数、警告文が記録されます。UI には直近 30 件が表示されます。データベースには最大 1000 件が保持され、自動的にローテーションされます。
• 同じデータは、ozon_diagnostics ツールを使ってチャットからも確認できます。

劣化検出

サーバーは、ドキュメントや失敗した作業を通じてではなく、自身の統計情報から、Ozon がエンドポイントを停止または無効化したことを自動で検知します。直近 3 回連続で呼び出しに失敗し、それ以前の呼び出しは成功していたツールは、劣化リストに表示されます。このリストには、ツール名、最後に成功した呼び出しの時刻、連続エラー数、最新のエラー内容が含まれます。ダッシュボードでは赤いバナーとして、診断ページでは表として表示されます。

これにより、Ozon 側の変更が起きたその日に把握でき、価格が更新されていないことに 1 週間後に気づくような事態を避けられます。同じリストは、ozon_degradations を使ってチャットからも確認できます。

外部モニタリング用 JSON

上記の情報は、画面で確認するだけでなく、プログラムから取得することもできます。

エンドポイント	返される内容
GET /api/health	サービスのステータス、認証が有効かどうか、最近のチェック結果、劣化したツール
GET /api/stats	ダッシュボードと同じ概要。?shop= を指定すると、1 つのストアに絞り込めます
GET /api/diagnostics/{shop_id}	1 つのストアに対する完全なリアルタイム診断

これだけで、サーバーを Zabbix、Uptime Kuma、または cron で実行する単純な curl に接続できます。

コンテキストの予算

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

定義。 単一のストアを設定した状態で、156個のツールに必要なトークンは 12 300 です。以前の18 386から削減されました。説明を1文にし、ストアが1つだけの場合はスキーマから shop_id を削除し、空のスキーマフィールドをなくしました。

応答。 実際の問題は、一部の巨大なペイロードにあることがわかりました。

ツール	変更前	変更後
ozon_category_tree — 9 797ノードのツリー	266 324	979
ozon_get_prices — データ量の93％がプロモーション履歴	52 879	8 679
ozon_returns_fbo — ロジスティクス情報をすべて含む50件の返品	24 277	8 458
ozon_warehouse_list — データ量の99％が1年分のスケジュール	20 132	370
実際の16件の応答からなるコーパス	476 158	63 845

サーバー側での対策は次のとおりです。

• view: compact | full。 重いツールは呼び出しに必要なフィールドを返します。view="full" を指定すると API の生の応答が返され、回答には非表示にしたフィールドが示されるため、モデルは何を要求できるか把握できます。
• 切り詰めの通知。 レコードがちょうど limit 件返された場合、回答でデータが一部であることを伝えます。そうしないと、モデルは一部のデータだけをもとに推論し、カタログ全体を示しているかのように提示してしまいます。
• サイズ制限。 クライアントの出力上限（Claude Code ではデフォルトで25 000の MAX_MCP_OUTPUT_TOKENS）に収まらない応答は、受信時に黙って切り詰めるのではなく、除外された件数を添えてサーバー側で切り詰めます。
• カテゴリーツリーの検索と階層の深さ。 API にはどちらもなく、9 797個のノードをすべて返します。search でカテゴリーを検索し、depth で階層の深さを指定できます。デフォルトでは最上位の階層のみを返します。

Ozon のエンドポイントの中にはトップレベルに配列を返すものが複数あるため、注記は JSON 内のフィールドではなく、個別のコンテンツブロックとして返します。配列をラップすると、データへのすべてのパスが壊れてしまうためです。

ツールプロファイル。 ツール検索に対応していないクライアントは、リクエストのたびにカタログ全体のコストを負担します。OZON_TOOLSETS を使うと、ドキュメントのセクションではなく実際の作業内容に沿って分けられたプロファイルから、使用するものだけを有効にできます。

OZON_TOOLSETS	ツール数	トークン数
空（デフォルト）	151	12 686
pricing,ads	57	5 425
orders	33	2 611

core プロファイル（ストア、診断、機能低下、会社）は常に有効です。何かが壊れたときこそ、診断が必要になるためです。無効なプロファイルは ozon_list_shops の説明に一覧表示され、無効なツールを呼び出すと、そのツールが含まれるプロファイルが回答されます。そのため、アシスタントは「できません」と言うのではなく、理由を説明できます。

Claude Code では、これらは必要ありません。デフォルトでツール検索が有効になっています。Cursor、Cline、Continue、Claude Desktop は tools/list を全件取得するため、プロファイルはそれらのクライアント向けです。

設計上の判断

• 汎用的なツールを少数用意するのではなく、用途を絞ったツールを151個用意します。 これらをaction形式のエンドポイントにまとめれば定義トークンを節約できますが、障害の種類が変わります。「そのようなツールはない」ではなく、副作用を伴う誤った呼び出しが発生するようになります。これらのツールの中には、価格を設定したり広告キャンペーンを開始したりするものもあります。
• サーバー自身が状態を診断します。 ozon_diagnosticsはホストの可用性を確認し、12のSeller APIカテゴリとPerformance APIキーを対象に軽量な実リクエストを実行します。ozon_degradationsは、以前は動作していたのに現在は継続的に失敗しているツールを報告します。Ozonは予告なくエンドポイントを廃止するため、「キーに問題があるのか、APIが変更されたのか」を1回の呼び出しで確認できる必要があります。
• 負荷の大きいツールではcompactをデフォルトにします。 コーパスから分かったのは、隠されるフィールドはプロモーション履歴、倉庫の営業時間、物流の内部情報であり、意思決定に使われるデータではないということです。また、レスポンスには何が隠されたかが示されます。
• レスポンスの整形にはcontextvarを使います。 ここでのディスパッチャーは150個の_json呼び出しが並ぶ長いifチェーンです。すべての分岐にツール名と引数を手作業で渡すと、編集箇所が150か所になり、見落としが起きる機会も150回になります。
• ストアが1つの場合、スキーマからshop_idがなくなり、2つ目が追加された時点で再び表示されます。
• mcp<2に意図的に固定しています。 2.0の低レベルAPIでは、このサーバーが基盤としているデコレーターハンドラーが削除されます。固定の理由は設定箇所に記載されています。
• キーは保存時に暗号化されます（Fernetを使用し、キーはデータボリュームに保存）。UIではマスキングされ、コーパス収集ツールはファイルに書き込む前に個人データをマスキングします。

仕組み

MCP サーバーとWeb UIを兼ねるFastAPIアプリケーションを、単一のDockerコンテナで実行します。

• ozon_mcp/server.py — MCP サーバー本体です。TOOLSリストには、すべての156個のツール（名前、説明、引数のJSONスキーマ）が定義されており、call_toolハンドラーは各呼び出しを適切なOzonクライアントメソッドに振り分けます。クライアントはshop_idごとにプールされるため、ストアを切り替えても再接続は発生しません。
• ozon_mcp/client.py — 2つのHTTPクライアントです。OzonSellerClient（Client-Id／Api-Keyヘッダー）とOzonPerformanceClient（client_credentialsトークンは30分間有効で、自動的に更新されます）。
• ozon_mcp/app.py — FastAPIです。SseServerTransport上の/sseエンドポイント、Bearerトークンの確認、ダッシュボード／ストア／診断ページ、バックグラウンドのヘルスチェックタスクを提供します。
• ozon_mcp/settings.py — ストアとキーを管理します。Fernet暗号化、UI向けのマスキング、環境変数のキーをdefaultというストアとして取り込み、旧形式の単一ストアsettings.jsonをshops.jsonに移行します。
• ozon_mcp/diagnostics.py — Ozonホストへのpingに加え、12のSeller APIカテゴリに対する軽量な実リクエストとPerformance APIキーの確認を行います。
• ozon_mcp/stats.py — aiosqlite経由でSQLiteを使用します。各ツール呼び出しの所要時間と結果、ヘルスチェックの履歴、劣化状況の計算を記録します。

サーバーが通信するホスト：

API	ベースURL	認証
Seller API	api-seller.ozon.ru	Client-IdとApi-Keyのヘッダー
Performance API（広告）	api-performance.ozon.ru	OAuth client_credentials、30分間有効なトークン

分かりにくい点：

• Ozonは広告の入札額と予算をマイクロルーブルで返します。1000000 = 1 ₽です。7桁の数値が返ってきても驚かないでください。
• レビューと質問に対する403は障害ではありません。Premium Plusのサブスクリプションがないことを示しています。診断ではエラーとしてカウントされません。
• 2026-02-13のローテーション以降、Ozon APIキーには有効期限が設けられ、180日間有効です。有効期限は明示的に確認できます。POST /v1/rolesはexpires_atを返すため、プローブで401を検知する前に警告できます。
• 非同期の広告統計では、一度に実行できるレポートは1つ、キャンペーンは最大10件、期間は最大62日です。ツールはレポートの準備が整うまで最大約2分待機します。
• API v3の納品注文ステータスは、文字列ではなく1～8の整数です。

環境変数

変数	デフォルト値	用途
MCP_AUTH_TOKEN	空	/sse 用の Bearer トークン。空の場合、認証なし
HEALTH_CHECK_INTERVAL_MIN	30	バックグラウンド診断の間隔。0 にすると無効になります
PORT	8000	HTTP サーバーのポート
OZON_TOOLSETS	空	カンマ区切りのツールプロファイル：pricing、ads、catalog、orders、analytics、feedback、finance。空の場合は全156個
OZON_MAX_RESPONSE_CHARS	60000	1つのレスポンスに対するサイズ上限
DATA_DIR	/data	shops.json、stats.db、.encryption_key を格納するディレクトリ
OZON_CLIENT_ID、OZON_API_KEY	空	UI を使わない場合の、default ストア用 Seller API キー
OZON_PERF_CLIENT_ID、OZON_PERF_CLIENT_SECRET	空	Performance API 用の同様のキー

既知の Ozon API の制限事項（2026年8月時点）

• 広告：API で作成できるのは「Trafarety」CPC キャンペーンのみです。予算と入札額の単位はマイクロルーブルです。広告アカウントの残高を取得する公式な方法はありません。

• 「注文ごとの課金」：2025年2月以降、入札額は固定されています。プロモーションのオン／オフのみ切り替えられます。

• レビュー、質問、一部の分析機能には Premium Plus のサブスクリプションが必要です（エラーコード 7）。

• ozon_analytics のファネル指標は Ozon により非推奨とされています。検索順位には ozon_product_queries を使用してください。

• Ozon が2026年秋に停止するエンドポイント。 公式の @OzonSellerAPI チャンネルで告知された日付を、実際のセラーアカウントで検証済みです (issue #6、 @standlord-prog に感謝します）：

  パス	停止日	代替
  /v3/posting/fbs/list	2026-08-31	/v4/posting/fbs/list — v2.1.0 で対応済み
  /v2/posting/fbo/list	2026-08-31	/v3/posting/fbo/list — v2.1.0 で対応済み
  /v3/posting/fbs/unfulfilled/list	2026-08-31	代替なし：ステータスによって /v4/posting/fbs/list から除外 — v2.1.0 で対応済み
  /v2/posting/fbs/act/create	2026-09-07	/v1/carriage/create + /v1/carriage/approve — 対応中
  /v3/finance/transaction/list	2026-09-08	/v1/finance/accrual/by-day — 対応中
  /v3/finance/transaction/totals	2026-09-08	同上 — 対応中

  /v4/posting/fbs/list は v3 の名称変更版ではありません。postings は result の下ではなく最上位にあり、ページネーションも offset ではなくカーソルベース（has_next + cursor）です。

• ozon_finance_cash_flow と ozon_finance_accruals は、すでに新しいパス（/v1/finance/cash-flow-statement/list、/v1/finance/accrual/by-day）を使用しています。

• ozon_product_stocks_by_warehouse は、v1 が2026-04-07に停止されたため、v2 を使用しています。

• デジタル FBS の引き渡し書類は2026-03-22に Ozon により廃止されました。代わりに通常の書類を使用します。

• Ozon API には「レビュー返信を編集する」メソッドがありません。返信を削除して書き直します。

この一覧はリファレンスをそのまま書き換えたものではありません。劣化記録と5か月間の日次呼び出しの結果をもとに、2026年8月時点の docs.ozon.ru と照合しています。

バージョン2.0での変更点

2026年6月の Ozon API に合わせた全面的な改訂です。ドキュメントを読むだけでなく、実際にリクエストを実行して検証しています。統合返品一覧、キャンセル v2、販売実績 v2、出荷 v4、供給注文 v3、実際の価格戦略と「割引を希望する」、セラー自身のプロモーション、新しい広告モデル（Trafarety CPC +「注文ごとの課金」）、劣化検知機能付き診断、MCP エンドポイントの認証に対応しました。

プロジェクトの構成

ozon-mcp-server/
├── docker-compose.yml   # port 8000, ozon_data volume
├── Dockerfile           # python:3.12-slim, uvicorn
├── DEPLOY.md            # deploying to a dedicated machine, moving data
├── docs/                # client connection guides + tool reference
└── ozon_mcp/
    ├── server.py        # MCP server: 156 tools, multi-store
    ├── client.py        # Seller API + Performance API
    ├── app.py           # FastAPI: SSE, web, auth, health loop
    ├── diagnostics.py   # category probes, degradation detector
    ├── settings.py      # stores and keys (Fernet)
    ├── stats.py         # call statistics and check history (SQLite)
    └── templates/       # dashboard, diagnostics, shops

専用マシンへのデプロイとストアの移行については、DEPLOY.md（ロシア語）をご覧ください。

Wildberries 向けの同じサーバー

wb-mcp-server は、もう一方のマーケットプレイス（Wildberries はロシアのもうひとつの大手マーケットプレイス）向けの同じツールです。アーキテクチャ、ダッシュボードと診断機能を備えた Web UI、shop_id による複数ストアモデル、SSE トランスポート、クライアントの接続方法はすべて同じです。

	Ozon MCP Server	WB MCP Server
ポート	8000	8001
ツール	151	202
API	Ozon Seller API + Performance API（広告）	Wildberries Seller API

実際には、次の2つを意味します。

• 2つ目のサーバーを使うために、新たに習得することはありません。 片方をセットアップすれば、もう片方も同じ方法で起動できます。違うのはポート（8000 ではなく 8001）とツールセットだけです。
• 1台のマシンで両方を実行できます。 ポートは別々で、データも別々の Docker ボリュームに保存されるため、競合しません。クライアントからは、http://localhost:8000/sse の ozon と http://localhost:8001/sse の wb という2つの MCP サーバーとして認識されます。

同じマシンを共有しても、レート制限には影響しません。どちらも同じ IP から接続しますが、Ozon と Wildberries はそれぞれ独自に制限をカウントします。マーケットプレイスが異なるためです。複数ストアのセクションで説明した販売者アカウント数の上限は、各マーケットプレイスで個別に適用されます。

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

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

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

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

更新とサポート

Ozon は API を頻繁に変更します。エンドポイントが追加、改名されたり、廃止されたりします（これまでに確認された制限については、上記の制限のセクションをご覧ください）。このサーバーは作者が実際に使っているツールであり、作者が更新を必要としたときに更新されます。つまり、作者自身のストアで変更による不具合が発生したときです。5か月以上にわたる毎日の利用実績があり、コミットは定期的にではなく、Ozon の変更で何かが壊れたときに行われます。通常、コミットの間隔が空いているのは、すべて正常に動作していることを意味します。実際に毎日使われており、公開後に放置されていないコードであることが利点です。一方、リリース予定はなく、対応時期の確約もありません。

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

謝辞

• @standlord-prog:
  • issue #6 — 実際の販売者アカウントで検証された、Ozon エンドポイントの停止に関する詳細な情報です。停止日、代替手段、/v4 への移行時に注意すべき 3 つの点が含まれています。別途、/v1/carriage/create には必須フィールドがなく、空の {} ボディで実際の出荷が作成されるという警告と、POST /v1/roles が expires_at を返すという修正も提供されました。バージョン v2.1.0 はこの取り組みを基盤にしています。
  • PR #7 — 診断機能の問題を発見し、修正しました。stdio モードでは呼び出し統計が初期化されていなかったため、ozon_degradations はすべての呼び出しが失敗している場合でも、どんな質問にも「劣化はありません」と回答していました。このツールは [P0] としてマークされており、何かが壊れたときにこそ正確に呼び出されるため、誤った結果を黙って返すことは、ツールがないよりも悪い状況です。この PR は配線を修正するだけでなく、「データがない」状態と「劣化がない」状態を区別し、実際の MCP クライアントを使用した stdio 経由の統合テストも追加しています。v2.1.2 でリリースされました。

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

ライセンス

MIT — LICENSE を参照してください。

MCP レジストリ

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

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