A primary-source review of MPP, Payment Auth, Tempo and HTTP 402 for the week ending July 26, 2026.
Last week’s review found a protocol whose implementation was outrunning its adoption evidence. This week narrows that gap a little, and it does so along an axis worth watching: MPP’s early adopters are no longer only AI-search and AI-content services.
I reviewed activity in the tempoxyz/mpp and tempoxyz/mpp-specs repositories, plus service and wallet documentation, for the seven days ending July 26. As always, catalog inventory is not treated as news on its own; I looked for verified endpoints, merged implementation and confirmed payment challenges.
Exa replaced its proxy with a native integration
Exa’s API at api.exa.ai now runs MPP first-party rather than through a proxy. POST /search prices dynamically between $0.007 and $0.015 per request, and POST /contents charges $0.001 per content type per URL. Payment is Tempo USDC.e, and the integration was verified through an actual 402 challenge carrying a WWW-Authenticate: Payment header — not just documentation describing the intent.
That distinction matters more than it sounds. A proxy-based integration can be a wrapper maintained by a third party. A first-party 402 challenge means the service itself is enforcing payment terms at the HTTP layer. It’s a small technical difference with a large signal value: the provider, not an intermediary, now owns the payment surface.
The catalog widened into data APIs
Four public database services — Apex DB, RxAtlas, TrialBase DB and RecallRadar — were added with production API origins, OpenAPI/llms.txt discovery, and Tempo USDC.e as the default payment method. All four search endpoints are registered on MPPScan and return production MPP challenges for both Tempo and EVM methods, and the additions went through the project’s own validation gate: pnpm check:ci, type checks, vitest schema tests, a build, and mppx discovery validation.
I’m treating this as implementation evidence, not demand evidence. A registered endpoint that returns a correct challenge proves the service is wired up. It does not prove anyone is paying it. But the direction is still notable: the first wave of MPP services was almost entirely AI inference and search. Data APIs are a different buyer profile — often internal tooling, research and compliance workflows rather than agent-native products — and their presence suggests the protocol is being evaluated as general API-monetization infrastructure, not just an AI-specific payment rail.
The ecosystem’s supporting layer got more concrete
Three other additions describe how MPP payments get authorized, wrapped and held, rather than which services accept them:
- An OpenClaw partner integration guide documents patterns for OpenClaw’s own API usage through MPP payments.
- @bolyra/mpp, published on npm under MIT and tested against
mppx0.8.6, adds authorization middleware that verifies an agent’s spend mandate before a payment flow proceeds — a check that sits between “the agent wants to pay” and “the agent is allowed to.” - Kite Passport wallet documentation describes owner-set guardrails — per-transaction and total spend caps, asset and merchant allowlists, TTLs, passkey approval — supporting
tempo.chargeandtempo.sessionmethods, verified against live endpoints at fal.ai, Exa and Anthropic, and deployed natively to Tempo chainId 4217 in USDC.e.
None of these is a payment rail. Together they’re closer to a control plane: who’s allowed to spend, how much, and under what wallet-level constraints. That layer has to exist before MPP moves from single verified integrations to something an operations team would trust running unattended.
What I’m not calling adoption yet
Five additions in one week, three services now with first-party or verified 402 behavior, and expansion outside AI — that’s a good week for a protocol still early in its life. It’s not the same claim as sustained transaction volume. I don’t have traffic numbers, repeat-payment evidence or retention data for Exa or the four database APIs, and I’m not going to infer them from a merged PR.
The honest framing: implementation surface area keeps growing, first-party integration is now demonstrated rather than theoretical, and the buyer base is starting to diversify. What to watch next is whether that translates into services staying live and getting paid, not just staying listed.
I built MPP Pulse to track exactly that distinction week over week. It’s an open-source AWS agent that collects primary evidence, treats catalog entries as inventory rather than news, and drafts a cited weekly brief for human review.