# MCPFax Bazaar Intelligence

> Paid market intelligence for the x402 agent economy: observed Base USDC money flow, daily movement, new entrants, category demand, and adverse-change alerts.

Base URL: use the origin serving this file.
MCP: POST /mcp (JSON-RPC 2.0, streamable HTTP)
x402: version 1, exact scheme, native USDC on Base. The network identifier emitted in every challenge is exactly "base" — the named form the standard x402 client libraries accept. eip155:8453 is the CAIP-2 label for the same chain and is never put on the wire.
Payment request carriers accepted: X-PAYMENT and PAYMENT-SIGNATURE
Payment response carriers: X-PAYMENT-RESPONSE and PAYMENT-RESPONSE

## Free

- GET / — product and per-call price catalog (HTML)
- GET /health — core status, configuration, source freshness, and the real observation window; no secrets
- GET /llms.txt — this file
- GET /server.json — MCP registry manifest
- POST /mcp — MCP handshake and tools/list are free; tool calls are individually paid

## Paid HTTP endpoints

- GET /market-report — $0.50 — daily state, observed totals/growth, top sellers, categories, movers
- GET /seller-rank?category=&limit= — $0.003 — observed-inflow leaderboard with HHI, effective payers, and wash-risk flags
- GET /trending?limit= — $0.003 — positive comparable-window transfer/inflow movement
- GET /new-entrants?since=YYYY-MM-DD&limit= — $0.003 — first-observed listings, ranked so
  entrants carrying a declared payTo, an observed title or observed inflow come first. A window
  whose first observations identify nobody is refused 422 and charges nothing.
- GET /category-demand?category= — $0.02 — demand vs classified supply and transparent opportunity index
- GET /movers?limit= — $0.003 — sudden inflow and first-observed-window large-payer signals

Allowed categories: crypto-defi, market-data, search-research, ai-inference, developer-infrastructure, risk-identity, commerce, automation, communications, other.

## Subscriber resources

Not offered on this deployment. /reports/* and /alerts return 503 subscriber_tier_not_offered. No subscription is sold, no price is advertised, and nothing here requires one. Everything purchasable is the per-call x402 list above.

## Payment flow

1. Call a paid HTTP endpoint without payment.
2. Read the base64 PaymentRequired object from PAYMENT-REQUIRED (also X-PAYMENT-REQUIRED).
3. Sign its exact USDC authorization.
4. Retry with the base64 PaymentPayload in X-PAYMENT or PAYMENT-SIGNATURE.
5. On success, read the base64 settlement receipt from PAYMENT-RESPONSE or X-PAYMENT-RESPONSE.

You are not charged for an error. The handler runs before settlement is requested: if the query fails, an error is returned and settle is never called.

For MCP, an unpaid tools/call returns PaymentRequired in both result.structuredContent and result.content[0].text. Retry with the PaymentPayload at params._meta["x402/payment"]. Settlement is returned at result._meta["x402/payment-response"].

## Coverage and honesty

Every paid response carries a coverage.observation_window block stating the REAL first observation date and how many calendar days of data actually exist. No endpoint claims a 30-day, 90-day, or otherwise longitudinal window that the data does not cover; where a nominal window (for example a 7-day comparison) exceeds what is held, the response says so and reports the days actually held. Request windows that begin before the archive does are reported as partially covered.

Wash risk is rated only above a coverage floor. A seller with fewer than 3 observed transfers, or with no payer rows at all, is returned as "unrated" with a neutral explanation of what is missing. Absence of data is never mapped to a risk verdict, because these verdicts are published beside a named host, its wallet, and a named third-party payer wallet.

The wash adjustment (organic_factor = concentration_factor x payer_graph_factor) is only meaningful once most declared payTo wallets have been scanned: payer out-degree cannot see payments made to unscanned sellers. While wallet scan coverage is below 80%, every adjusted figure is set to null with adjustment_status "suppressed_coverage_limited", and all ranking is done on the OBSERVED figure. adjustment_coverage on each response states the current coverage and threshold.

## Data semantics

Observed inflow is incoming native-USDC Transfer logs to declared payTo wallets on Base. It is not current balance, audited revenue, ownership proof, or guaranteed x402-only attribution. HHI and effective payer count measure concentration, not common control. Flags indicate wash risk; they do not prove self-dealing.

Daily buckets are derived by the upstream Observatory from block-height time estimates. Per-wallet scan windows can start on different blocks. wallet_payers has all-window aggregates but no payer first-seen date; the API therefore does not fabricate daily unique-payer deltas. Category labels are deterministic keyword classifications of enrichment IDs/titles, and shared-wallet demand is allocated evenly across distinct matched categories.