New X402 Listings Feed MCP server

New x402 Listings Feed

Feed of x402/L402 services newly listed on 402index.io within a caller-specified recency window. NEXUS candidate #8 -- manual build, not FORGE-generated, same manual-Cloud-Run-asset pattern as candidates #3 (agent-verification-api), #4 (url-metadata-api) and #6 (document-conversion-api).

-- services registered on 402index.io within the window (1-168h, default 24). $0.01/call.

• POST /new-x402-listings {"windowhours": 24, "protocol": null, "category": null, "paymentnetwork": null}

GET /.well-known/402index-verify.txt (402index claim verification file).

• MCP tool getnewx402listings at /mcp, same params -- currently free**, see "Known limitations".
• GET /health, GET /.well-known/agent-card.json, GET /openapi.json (has x-payment-info),

Mainnet cutover (2026-09-03)

Originally built and measured on Base Sepolia testnet. Cut over to Base mainnet: x402 settlement moved to the CDP facilitator (createfacilitatorconfig(), same swap already applied to ws/live-entity-verification/erc8004-agent-liveness/onchain-activity-index/x402-receipt-verifier), and the payto wallet moved to NEXUSX402PAYTOADDRESS (fail-fast env var, no placeholder default, renamed from X402WALLETADDRESS). CDPAPIKEYID/CDPAPIKEYSECRET and NEXUSX402PAYTOADDRESS must be set in Cloud Run before this deploys.

What this is (and isn't)

This is not exclusive data. The registration data underneath this asset is 402index.io's own free, public directory (https://402index.io/api-docs, no auth needed, 100 req/min free tier). Anyone can query it directly for nothing. This asset's value is entirely in the packaging: polling and paginating the ~96k+ entry catalog so a buyer doesn't have to, merging in 402index's own recency feed for freshness, deduping, and filtering to a caller's window/protocol/category/payment-network. This disclosure is not just in this README -- it's baked into the product itself: every response includes a note field stating it plainly, and the agent-card's protocol_note repeats it, so a buyer never has to dig for it.

Feasibility research (2026-08-23, before writing any code)

The task brief's premise cited a prior-session figure of "~7,595 total services" on 402index.io. A real curl https://402index.io/api/v1/services?limit=5 at the start of this session showed "total": 96093 -- the catalog grew roughly 12x since that check. registered_at is real and populated on every entry sampled. Two upstream mechanisms were verified live, each with a real limitation neither the task brief nor 402index's own docs fully surfaced:

filter -- sort only accepts name/price/latency/uptime/reliability (checked /api-docs directly). A window query can only be answered by walking the entire catalog and filtering client-side -- there is no cheaper server-side path. At the real current size that's ~481 pages, not the ~40 pages the ~7,595 figure would have implied.

1. GET /api/v1/services (paginated, limit/offset, max 200/page) has NO sort-by-date or date-range

402index's own documented rate-limit-exempt list. But it's capped to a fixed item count: a live fetch during this session returned exactly 90 items spanning only ~3 hours, despite the docs describing type=new as "services added in the last 7 days". At current registration velocity it does not cover a 7-day (or even a 24h, at peak velocity) window by itself.

1. GET /feed.xml?type=new is real, RSS 2.0, and IS already recency-sorted (pubDate) -- and is on

Neither source alone honestly satisfies the product's advertised window range. Decision: proceed, using both. See the main.py module docstring and "Architecture" below for how they're combined. This is the kind of real, current-data discrepancy CLAUDE.md SS3 asks to surface rather than build past silently -- so it's recorded here rather than only in a chat transcript.

Shortened. The full README is on GitHub.