mcpField
X
x402 Bazaar Listing Monitor

x402 Bazaar Listing Monitor

リモート
acjlabs.com金融データ112 週間前に更新
リポジトリ公式サイト

x402 Bazaar Listing Monitor について

x402 セラー向けのホスト型監視サービスで、登録したリソースが Coinbase CDP の公開 Bazaar カタログに掲載されているか確認します。掲載状態の変化を記録し、消失や復旧時に Webhook 通知を送信できます。

主な機能

  1. 01掲載状況のオンデマンド確認
  2. 026時間ごとの定期カタログ照合
  3. 03掲載状態の変化を時刻付きで記録
  4. 04状態変化時の Webhook 通知

活用シーン

  1. 01payTo アドレスに対するリソース掲載の確認
  2. 02リソースの掲載停止と復旧の追跡
  3. 03CDP への問い合わせ前に記録済み状態を確認

MCP 対応

Streamable HTTP 経由で `check_listing_health` ツールを提供します。登録済みかどうかにかかわらず、指定された `payTo` とリソース URL の組み合わせを公開ディスカバリーカタログと照合します。

設定

リモートサーバーはインストール不要です。クライアントを選んで設定をコピーするか、ワンクリックで導入できます。

エンドポイントhttps://x402-listing-monitor.acjlabs.com/mcp
インストールコマンドをコピー
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

コマンドはターミナルで実行し、JSON は各クライアントの MCP 設定に貼り付けて再起動します。認可が必要なサーバーは初回接続時にログインを求めます。

ツール

1
パラメーター型必須説明
payTostringはい
resourcesarrayはい

詳細

x402 Bazaar Listing Monitor

x402 販売者向けのスケジュール実行型ウォッチドッグです。Coinbase CDP の公開 Bazaar 検索カタログを定期的に確認し、登録したリソースが掲載から消えたり、再び掲載されたりしたときに通知します。収益の減少に数日後に気づくという事態を防ぎます。

実際の x402 支払いを決済する販売者には、自分のリソースが CDP の Bazaar カタログで引き続き検索可能かどうかを確認する信頼できる方法がありません。検索 API には、決済が確認済みであるにもかかわらず、リソースがひそかに表示されなくなる不具合が繰り返し報告されています。現在、販売者がこれを検知するには、それぞれの都合に合わせて GET /discovery/merchant?payTo=<address> を手動で再実行するしかありません。

このサービスは、その確認を自動化します。payTo アドレスと提供するリソースの URL を登録すると、スケジュールされたポーリングで実際の検索カタログとの差分を確認します。状態の変化はタイムスタンプとともに記録されるため、CDP サポートへのエスカレーションが必要な場合に提示できる、永続的な履歴を保持できます。

MCP サーバー

エンドポイント: https://x402-listing-monitor.acjlabs.com/mcp(ストリーミング可能な HTTP)

ツールは 1 つです。登録や API キーは不要です。

check_listing_health

公開検索カタログで、指定した payTo アドレスに x402 Bazaar リソースが現在掲載されているかを確認します。登録済みかどうかにかかわらず、任意の payTo とリソースの組み合わせについて、スケジュール実行型ポーリングと同じ販売者ごとの差分確認をオンデマンドで実行します。

パラメーター型備考
payTostring0x で始まる 40 桁の 16 進数
resourcesstring[]http(s) URL を 1~200 件

各リソースについて、掲載中か見つからないかを示す JSON を返します。

HTTP API

ベース URL:https://x402-listing-monitor.acjlabs.com

メソッドパス目的
GET/health稼働確認
POST/register販売者を登録してスケジュールポーリングの対象にする
GET/status自分の現在のステータスと最近のアラートを確認する
POST/pollポーリングを直ちに実行する(件数のみ。詳細は下記を参照)
POST /register
{
  "sellerId": "your-slug",
  "payTo": "0x0000000000000000000000000000000000000000",
  "resources": ["https://api.example.com/your-resource"],
  "alertWebhookUrl": "https://example.com/hook"
}
  • sellerId — 2~64 文字:英字、数字、-、_
  • payTo — 0x で始まる 40 桁の 16 進数
  • resources — http(s) URL を 1~200 件。重複不可
  • alertWebhookUrl — 任意。公開 https URL を指定します。プランで利用できるアラートは、この URL に POST されます。IP アドレスを直接指定した URL、ループバック、.internal/.local のホスト、および認証情報を含む URL は拒否されます。
  • alertEmail — 任意ですが、保存されるだけで、まだ使用されません。メール通知は有効になっていません(「ステータス」を参照)。

どちらの連絡先フィールドも任意で、いずれも指定せずに登録できます。どちらも指定しない場合、通知は送信されません。掲載状況は、下記の GET /status でご自身で確認してください。

リソースの監視は自己申告制です。サービスは、確認するよう指定された対象をチェックします。すでに存在する sellerId は、上書きされずに拒否されます。

GET /status
GET /status?sellerId=your-slug&payTo=0x0000000000000000000000000000000000000000

ご自身のレコードを返します。登録したすべてのリソースについて、現在のステータス(listed、missing、payTo-mismatch、またはまだポーリングされていない場合は null)、連続して見つからなかった回数、最終確認日時に加え、直近のアラートとそれぞれの配信状況が含まれます。

sellerId と payTo の両方が必須で、登録内容と一致している必要があります。それ以外の場合は 404 を返します。これは認証ではなく、情報確認のためのものです。返されるデータは公開カタログとの差分です。alertEmail と alertWebhookUrl の値がそのまま返されることはなく、設定済みかどうかのみが示されます。

POST /poll

登録済みのすべての販売者に対して、6時間ごとの cron と同じポーリングを直ちに実行します。リクエスト本文は不要で、件数のみを返します。

{ "polled": 2, "ok": 2, "failed": 0 }

個々の販売者についての情報は一切報告しません。このエンドポイントは認証なしで利用できるため、返される情報はすべて公開されます。代わりに、GET /status でご自身の状態を確認してください。

ポーリングは同時に1つだけ実行されます。すでにポーリングが進行中の場合(別のユーザーが開始した場合でも、6時間ごとの cron が開始した場合でも)、このエンドポイントは 409 を返し、処理を行いません。

{ "status": "already_running" }

これは再試行するエラーではありません。リクエストしたポーリングはすでに実行中であり、再試行してもアラートが早く届いたり、二重に届いたりすることはありません。このロックにより、同時に実行された2つのポーリングから同じアラートが送信されるのを防ぎます。これは重複を防ぐ保証であり、配信を保証するものではありません。アラートは必ず送信前に記録され、送信に失敗した場合は再試行されず、未配信のまま記録に残ります。しばらく待ってから GET /status を確認してください。最近の各アラートと、配信済みかどうかを確認できます。

/register、/status、/poll、MCP ツールの呼び出しには、IP ごとのレート制限が適用されます。

Webhook ペイロード
{
  "service": "x402-listing-monitor",
  "sellerId": "your-slug",
  "checkedAt": "2026-08-07T00:00:00.000Z",
  "alerts": [
    {
      "type": "listing-dropped",
      "resource": "https://api.example.com/your-resource",
      "detail": "was listed, now missing from discovery",
      "message": "⚠️ Listing dropped: https://api.example.com/your-resource — was listed, now missing from discovery"
    }
  ]
}

checkedAt はポーリングのタイムスタンプで、GET /status にある同じアラートの created_at と一致します。2xx のレスポンスはすべて配信済みとして扱われます。リダイレクトは追跡されません。3xx は配信失敗として扱われるため、最終 URL を登録してください。配信失敗は再試行されず、アラートは未配信のマークが付いたまま履歴に残ります。

ポーリングとアラート

スケジュールされたポーリングは6時間ごとに実行されます。実行ごとに、登録済みのリソースと最新のディスカバリーカタログを比較し、状態の変化をタイムスタンプ付きで記録します。これは、ある時点の状態だけでなく、履歴を記録するものです。

アラートの種類ティア
リソースがカタログから消えた無料
インデックス作成の遅延に対する猶予期間後も見つからない無料
リソースが復旧した無料
登録済みの payTo がカタログエントリーにない有料
カタログの品質/ランクが低下した有料

「引き続き見つからない」アラートは、リソースが3回以上連続するポーリングで見つからなかった場合に、その連続不在期間につき1回だけ発生します。これは、インデックス作成の遅延ではないと判断できる長さです。リソースが見つからないままでも、6時間ごとに繰り返し発生することはありません。現在の状態はいつでも GET /status で確認できます。

連続して3回見つからない場合は、アラートが発生しうる最も早いタイミングですが、それだけではありません。すでに連続して3回以上見つからず、その期間についてまだアラートが発生していないリソースは、次回のポーリングで1回アラートが発生します。リソースが復旧した後、再びカタログから消えた場合は、新たな連続不在期間となり、再度アラートが発生します。

有料ティアでは、ポーリング間隔も短くなります。

ステータス

早期リリースです。サービスは稼働してポーリングを行っており、記録されたアラート履歴が、サービスが観測した内容を示す正式な記録です。

  • Webhook 配信は有効です。 https の alertWebhookUrl を登録すると、チェックでアラートが発生した際に、ご利用のプランで対象となるアラートがその URL に POST されます。
  • メールアラートはまだ有効になっていません。 alertEmail は登録情報に保存されますが、その宛先には何も送信されません。
  • 連絡先の登録は不要です。 GET /status を使うと、同じ情報をいつでも確認できます。

ソースの公開状況とサポート

このリポジトリでは、ホスト型サービスのドキュメントを公開しています。サービスの実装はオープンソースではありません。バグ報告や機能リクエストは、このリポジトリの Issues で歓迎しています。[email protected] へのお問い合わせも可能です。

ソースの公開状況とサポート

このリポジトリでは、ホスト型サービスのドキュメントを公開しています。サービスの実装はオープンソースではありません。バグ報告や機能リクエストは、このリポジトリの Issues で歓迎しています。[email protected] へのお問い合わせも可能です。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。