Inspiration
The arrival of AI agents is dramatically changing how people consume web content. In the past, people would visit and read websites one by one. Today, AI can collect information on their behalf by scraping sources such as technical blogs.
This is a great user experience for end users. However, it can also mean that website operators and the businesses that advertise on those sites lose their opportunity to reach users.
This product was inspired by that problem. I wanted agents to be able to use a publisher’s structured capabilities while keeping people clearly in control of how access is granted. By combining WebMCP with x402, I wanted to explore a model where users who value convenience can make a micropayment for a nearly automated experience, while users who do not want to pay can access premium content by viewing a short advertisement.
What it does
For this project, I created a fictional recipe website. It includes a WebMCP-compatible tool called analyze_recipe, which provides more detailed analysis as a premium feature.
There are two ways to access the premium feature:
- View an owned sponsor message (advertisement) for eight seconds.
- Explicitly approve a 0.01 testnet USDC x402 payment on Base Sepolia.
Both paths authorize the same protected analysis endpoint. The original tool invocation then resumes with one structured result containing a recipe summary, nutrition notes, practical suggestions, and a general-information disclaimer.
The same gate is also used by the visible Analyze this recipe button, so people and agents use one coherent product flow rather than separate experiences.
I felt WebMCP was a good fit because agents can discover and invoke typed, page-owned capabilities instead of scraping a page or guessing which buttons to click. Users can make an important decision in the middle of the same invocation without losing the shared context.
How we built it
The React/Vite frontend registers analyze_recipe with
document.modelContext.registerTool, with a navigator.modelContext
compatibility fallback. A shared GateCoordinator keeps one request alive while
the page renders the sponsor or payment experience, propagates cancellation,
and resolves the result exactly once.
The x402-enabled resource server, built with Hono, manages authorization and canonical deterministic analysis. Sponsor sessions, single-use grants, and their consumption state are stored in a named Cloudflare Durable Object. For the payment path, the app displays Base Sepolia terms before wallet access and then uses x402 exact-payment authorization. An optional Hono/viem facilitator verifies and settles the testnet payment. The browser never holds a private key, and the AI never controls the wallet.
I used Codex to turn product decisions into executable specifications, build the frontend/server/facilitator boundaries, write focused tests, diagnose lifecycle and payment-receipt issues, create fake-host browser journeys, and run the final release checks. Human decisions remained explicit for product scope, payment policy, security constraints, deployment, and publication.
Both the frontend and backend are deployed on Cloudflare.
Challenges we ran into
One challenge was deciding how to combine WebMCP and x402, as well as who should manage the wallet and where it should be managed.
For the smoothest user experience, a server-managed wallet such as Privy could be a good option. However, this project focuses on WebMCP, where people and AI work together in a visible browser environment. For that reason, I deliberately chose a conventional MetaMask wallet for this demo.
This is only a choice for the current demo. In the future, I believe the product should support WalletConnect and allow users to choose flexibly between wallet options such as MetaMask and Privy.
With this architecture, I separated the responsibilities of AI and human interaction. The AI handles the process automatically up to the payment step. As the human-in-the-loop, the person reviews the payment details. If they decide not to pay, they can view an advertisement and be guided to premium access instead.
Designing this architecture was the most difficult part of the project.
Accomplishments that we're proud of
Although the development period was short, I am proud that I was able to learn WebMCP and combine it with x402 and Cloudflare technologies to turn this idea into a working product. I spent more time than usual thinking through the idea and designing the architecture.
It is a very simple demo, but I am proud that I was able to build it as a new advertising model for the AI-native era.
What we learned
The biggest lesson was gaining a practical understanding of WebMCP. Building with it helped me understand how it differs from MCP.
Because WebMCP is based in a visible browser environment, I think it makes it easier to build products with a clear separation of responsibilities between people and AI. I also found this to be highly compatible with x402.
What's next for AdGate
Next, I would like to expand this gate to other structured publisher resources, such as news, research, and creator tools. To make it more broadly useful, I would like to build a dashboard for sponsors and make the supported blockchains and assets more flexible.
For production, the payment path would need authentication, rate limits, monitoring, treasury controls, stronger key management, and evaluation of production payment rails. I would also like to explore privacy-preserving sponsor measurement and observability while maintaining a clear boundary for explicit human choice.
Built With
- base
- chatgpt
- cloudflare
- codex
- hono
- node.js
- openai
- playwright
- pnpm
- react
- typescript
- usdc
- viem
- vite
- vitest
- webmcp
- x402
- zod
Log in or sign up for Devpost to join the conversation.