X402 Listing Monitor MCP Server

x402 Bazaar Listing Monitor

Scheduled watchdog for x402 sellers: polls Coinbase CDP's public Bazaar discovery catalog for the resources you register and alerts when one drops out or comes back — instead of finding out from a revenue dip days later.

Sellers who settle real x402 payments have no reliable way to confirm their resources stay discoverable in CDP's Bazaar catalog. The discovery API has a recurring, publicly-reported class of bug where a resource silently stops appearing despite confirmed settlements — sellers currently catch this only by manually re-running GET /discovery/merchant?payTo=<address> on their own schedule.

This service automates that check: register your payTo address and the resource URLs you serve, and a scheduled poll diffs them against the live discovery catalog. State changes are recorded with timestamps, so you have a durable history you can cite if you need to escalate to CDP support.

MCP server

Endpoint: https://x402-listing-monitor.acjlabs.com/mcp (streamable HTTP)

One tool — no signup, no API key:

check_listing_health

Checks whether a seller's x402 Bazaar resources are currently listed under a given payTo address in the public discovery catalog. Runs the same per-seller diff as the scheduled poller, on demand, for any payTo/resources pair — registered here or not.

Returns each resource flagged as listed or missing, as JSON.

HTTP API

Base URL: https://x402-listing-monitor.acjlabs.com

POST /register

{
  "sellerId": "your-slug",
  "payTo": "0x0000000000000000000000000000000000000000",
  "resources": ["https://api.example.com/your-resource"],
  "alertWebhookUrl": "https://example.com/hook"
}

• sellerId — 2–64 characters: letters, digits, -, _
• payTo — 0x-prefixed, 40 hex characters
• resources — 1–200 http(s) URLs, no duplicates
• alertWebhookUrl — optional. A public https URL; alerts on your plan are POSTed to it. IP-literal, loopback, .internal/.local hosts and URLs carrying credentials are rejected.
• alertEmail — optional, and stored but not yet used: email delivery is not enabled (see Status).

Both contact fields are optional and registration succeeds without either. Supply neither and nothing is pushed to you — use GET /status below to check on your listings yourself.

Resources are watched by self-declaration: the service checks what you tell it to check. A sellerId that already exists is rejected rather than overwritten.

GET /status

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

Returns your own record: every resource you registered with its current status (listed, missing, payTo-mismatch, or null if no poll has reached it yet), its consecutive-miss count and last-checked timestamp, plus your most recent alerts and whether each was delivered.

Both sellerId and payTo are required and must match your registration; anything else returns 404. This is a knowledge check, not authentication — the data it returns is a diff against a public catalog. Your alertEmail and alertWebhookUrl are never echoed back, only reported as set or not set.

POST /poll

Runs the same poll the six-hourly cron runs, immediately, for every registered seller. Takes no body and returns counts only:

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

It reports nothing about any individual seller. This endpoint is unauthenticated, so anything it returned would be public — read your own state with GET /status instead.

Only one poll runs at a time. If a poll is already in progress — whether someone else triggered it or the six-hourly cron did — this returns 409 and does no work:

{ "status": "already_running" }

That is not an error to retry through: the poll you asked for is already happening, and retrying cannot make its alerts arrive sooner or arrive twice — the lock is what stops two concurrent polls from sending you the same alert. It is a guarantee against duplication, not a delivery guarantee: an alert is always recorded before it is sent, and if the send does not land it stays recorded and undelivered rather than being retried. Wait, then read GET /status, which shows each recent alert and whether it was delivered.

Per-IP rate limits apply to /register, /status, /poll and MCP tool calls.

Webhook payload

{
  "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 is the poll's timestamp, matching created_at on the same alerts in GET /status. Any 2xx counts as delivered. Redirects are not followed — a 3xx is treated as a failed delivery, so register the final URL. Failed deliveries are not retried; the alert stays in your history marked undelivered.

Polling and alerts

The scheduled poll runs every 6 hours. Each run diffs your registered resources against the live discovery catalog and records state changes with timestamps — a history, not just a point-in-time answer.

"Still missing" fires once per miss streak, from the first poll at which a resource has been absent for three or more consecutive polls — long enough that indexing lag is ruled out. It does not repeat every six hours while the resource stays missing; the current state is always readable from GET /status.

Three consecutive misses is the earliest it can fire, not the only point at which it can. A resource that is already past three consecutive misses and has not yet been alerted for that streak raises its one alert on the next poll. If the resource recovers and later drops out again, that is a new streak and it alerts again.

Paid tiers also tighten the polling interval.

Status

Early release. The service is live and polling, and the recorded alert history is authoritative for what it has observed.

• Webhook delivery is enabled. Register an https alertWebhookUrl and alerts on your plan are POSTed to it when a check produces one.
• Email alerts are not enabled yet. alertEmail is stored against your registration and nothing is sent to it.
• No contact is required. GET /status gives you the same information on demand.

Source availability & support

This repository hosts the documentation for the hosted service. The service implementation is not open source. Bug reports and feature requests are welcome in this repo's Issues; you can also reach us at contact@acjlabs.com.

Source availability & support

This repository hosts the documentation for the hosted service. The service implementation is not open source. Bug reports and feature requests are welcome in this repo's Issues; you can also reach us at contact@acjlabs.com.