Add x402 monetization - let AI agents pay per API call#136
Add x402 monetization - let AI agents pay per API call#136sam00101011 wants to merge 1 commit intosupermodeltools:mainfrom
Conversation
WalkthroughTwo new files introduced to support the x402 payment protocol: a JSON configuration file describing a "supermodeltools/mcp" service with pay-per-call pricing for three endpoints, and a TypeScript example demonstrating middleware that checks for payment headers and verifies signatures with a payment facilitator. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.well-known/x402.json:
- Line 8: Replace the placeholder string "YOUR_WALLET_ADDRESS" in the JSON key
"address" with a real Base network wallet address (the actual wallet public
address string) so the config is valid; locate the "address" field in the
.well-known x402 JSON and update its value to the correct address (or inject it
from a secure source) ensuring it matches the expected Base address format.
- Around line 11-27: This x402 config incorrectly declares HTTP endpoints for
functionality that's exposed via MCP/stdio (delete the file). Remove
.well-known/x402.json from the repo because the server uses StdioServerTransport
(see src/server.ts) and the listed items are not HTTP routes: symbol_context is
an MCP tool implemented in src/tools/symbol-context.ts, explore_function is an
MCP tool in src/tools/explore-function.ts, and precache is a CLI startup
flag—not a callable endpoint; if you truly want payment-protected HTTP paths you
must instead implement an HTTP server and route wrappers (for example, adapt
x402-middleware-example.ts and replace StdioServerTransport with an HTTP
transport), otherwise delete the x402 file to avoid misleading configuration.
In `@x402-middleware-example.ts`:
- Around line 13-14: Payment verification currently depends on the centralized
facilitator endpoint "https://facilitator.402.bot/verify", which creates an
SPOF; update the code/docs to either (a) document this external dependency and
its required availability in the payment flow, and (b) add a configurable
fallback so the system can verify signatures locally or via an alternative
verifier if the facilitator is unavailable—introduce a config flag (e.g.,
useFacilitatorVerify) and implement a local verification path that uses the
payment signature and known public keys to validate signatures when
useFacilitatorVerify is false or the facilitator request fails (log and surface
clear errors referencing the facilitator URL and the local verification path).
- Around line 1-16: This file (x402-middleware-example.ts) isn't integrated and
the HTTP-header-based approach is incompatible with our MCP stdio transport;
either remove the misleading example or reimplement payment enforcement inside
the MCP JSON-RPC flow: locate the JSON-RPC request handling in src/server.ts
(the StdioClientTransport message/handleRpcRequest or whatever function
receives/parses incoming tool calls) and add a payment-check step that calls the
402 facilitator (POST to https://facilitator.402.bot/verify) before executing
the tool; on verification failure return a JSON-RPC error result indicating
payment required (instead of an HTTP 402), include facilitator response details
for debugging, and delete or replace x402-middleware-example.ts so docs don’t
suggest using HTTP headers with StdioClientTransport.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: cc958e23-2066-4606-946e-ec3428023d6e
📒 Files selected for processing (2)
.well-known/x402.jsonx402-middleware-example.ts
| { | ||
| "network": "eip155:8453", | ||
| "asset": "USDC", | ||
| "address": "YOUR_WALLET_ADDRESS" |
There was a problem hiding this comment.
Remember to replace the placeholder wallet address.
The YOUR_WALLET_ADDRESS placeholder needs to be swapped with an actual Base network wallet address before this config could work. Though given the architecture issues flagged above, you'll need to solve those first.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.well-known/x402.json at line 8, Replace the placeholder string
"YOUR_WALLET_ADDRESS" in the JSON key "address" with a real Base network wallet
address (the actual wallet public address string) so the config is valid; locate
the "address" field in the .well-known x402 JSON and update its value to the
correct address (or inject it from a secure source) ensuring it matches the
expected Base address format.
| "resources": [ | ||
| { | ||
| "path": "/symbol_context", | ||
| "price": "0.01", | ||
| "description": "Pay-per-call access to symbol_context" | ||
| }, | ||
| { | ||
| "path": "/explore_function", | ||
| "price": "0.01", | ||
| "description": "Pay-per-call access to explore_function" | ||
| }, | ||
| { | ||
| "path": "/precache", | ||
| "price": "0.01", | ||
| "description": "Pay-per-call access to precache" | ||
| } | ||
| ] |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if any HTTP server or Express/Fastify/etc is set up
echo "=== Checking for HTTP server setup ==="
rg -n --type=ts -C3 'express|fastify|createServer|http\.Server|app\.listen'
echo -e "\n=== Checking how server starts (should be stdio MCP) ==="
rg -n --type=ts -C3 'StdioServerTransport|stdio'
echo -e "\n=== Checking if middleware is imported/used anywhere ==="
rg -n --type=ts 'x402|402'Repository: supermodeltools/mcp
Length of output: 3651
These endpoint definitions won't work—the server doesn't actually have HTTP endpoints.
Here's the thing: this file describes payment protection for HTTP REST API endpoints, but this codebase is an MCP (Model Context Protocol) server that uses stdio (standard input/output) instead of HTTP. Think of it like someone building a payment gate for a physical storefront, but the actual business is entirely online and doesn't have that storefront.
Look at what's actually happening:
/symbol_context→ This is an MCP tool (insrc/tools/symbol-context.ts), not an HTTP route. Clients call it through the MCP protocol./explore_function→ Another MCP tool (insrc/tools/explore-function.ts), same story./precache→ A CLI flag that runs once when the server starts, not a callable endpoint at all.
The server boots up with StdioServerTransport (you can see it in src/server.ts), which means all communication happens through pipes, not HTTP requests. There's no web server listening on a port, no middleware checking headers, nothing that could return an HTTP 402 response.
The x402-middleware-example.ts file shows what payment protection would look like in Express or Fastify, but it's just an example—it's not actually imported or used anywhere in your server code.
Bottom line: Delete this x402 config entirely, or if you want payment protection, you'd need to fundamentally redesign the server as an HTTP REST API instead of MCP/stdio.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.well-known/x402.json around lines 11 - 27, This x402 config incorrectly
declares HTTP endpoints for functionality that's exposed via MCP/stdio (delete
the file). Remove .well-known/x402.json from the repo because the server uses
StdioServerTransport (see src/server.ts) and the listed items are not HTTP
routes: symbol_context is an MCP tool implemented in
src/tools/symbol-context.ts, explore_function is an MCP tool in
src/tools/explore-function.ts, and precache is a CLI startup flag—not a callable
endpoint; if you truly want payment-protected HTTP paths you must instead
implement an HTTP server and route wrappers (for example, adapt
x402-middleware-example.ts and replace StdioServerTransport with an HTTP
transport), otherwise delete the x402 file to avoid misleading configuration.
| // x402 payment check - framework-agnostic | ||
| // Before responding to API requests, check for the x-payment header. | ||
| // If missing, return HTTP 402 with your payment requirements: | ||
| // | ||
| // HTTP/1.1 402 Payment Required | ||
| // Content-Type: application/json | ||
| // | ||
| // { | ||
| // "accepts": [{ "network": "eip155:8453", "asset": "USDC", "address": "YOUR_WALLET" }], | ||
| // "price": "0.01" | ||
| // } | ||
| // | ||
| // If present, verify the payment signature with the facilitator: | ||
| // POST https://facilitator.402.bot/verify | ||
| // | ||
| // Full guide: https://api.402.bot/mcp/setup |
There was a problem hiding this comment.
This middleware example isn't integrated anywhere.
This file is just documentation/comments - there's no actual code here, and it's not imported or used in src/server.ts or anywhere else in the codebase.
But more fundamentally: this middleware assumes you're handling HTTP requests/responses with headers, status codes, etc. Your server is an MCP server using stdio transport (see StdioClientTransport in src/server.ts). MCP servers don't process HTTP requests - they communicate via JSON-RPC messages over standard input/output.
Think of it this way:
- HTTP server: Client sends
GET /explore_function→ Server checks payment header → Returns 402 or data - MCP server: Client sends JSON-RPC tool call over stdin → Server processes → Returns JSON-RPC response over stdout
There's no HTTP request cycle here where you could check headers or return 402 status codes.
To actually monetize MCP tool calls, you'd need a completely different approach - maybe wrapping the MCP server behind an HTTP proxy that handles x402, or extending the MCP protocol itself to support payments (which would require changes to MCP clients like Claude Desktop).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@x402-middleware-example.ts` around lines 1 - 16, This file
(x402-middleware-example.ts) isn't integrated and the HTTP-header-based approach
is incompatible with our MCP stdio transport; either remove the misleading
example or reimplement payment enforcement inside the MCP JSON-RPC flow: locate
the JSON-RPC request handling in src/server.ts (the StdioClientTransport
message/handleRpcRequest or whatever function receives/parses incoming tool
calls) and add a payment-check step that calls the 402 facilitator (POST to
https://facilitator.402.bot/verify) before executing the tool; on verification
failure return a JSON-RPC error result indicating payment required (instead of
an HTTP 402), include facilitator response details for debugging, and delete or
replace x402-middleware-example.ts so docs don’t suggest using HTTP headers with
StdioClientTransport.
| // If present, verify the payment signature with the facilitator: | ||
| // POST https://facilitator.402.bot/verify |
There was a problem hiding this comment.
External dependency on centralized facilitator service.
The payment verification relies on https://facilitator.402.bot/verify - this is a centralized service that becomes a single point of failure. If it goes down or changes its API, payment verification breaks.
The PR description mentions "direct settlement to wallet with no intermediary custody," but you're still dependent on this external facilitator for signature verification. Worth calling out in your docs that this service needs to be available for the payment flow to work.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@x402-middleware-example.ts` around lines 13 - 14, Payment verification
currently depends on the centralized facilitator endpoint
"https://facilitator.402.bot/verify", which creates an SPOF; update the
code/docs to either (a) document this external dependency and its required
availability in the payment flow, and (b) add a configurable fallback so the
system can verify signatures locally or via an alternative verifier if the
facilitator is unavailable—introduce a config flag (e.g., useFacilitatorVerify)
and implement a local verification path that uses the payment signature and
known public keys to validate signatures when useFacilitatorVerify is false or
the facilitator request fails (log and surface clear errors referencing the
facilitator URL and the local verification path).
What is this?
x402 is an open protocol that lets AI agents pay for API calls using the HTTP 402 status code. Instead of API keys and billing dashboards, agents pay per call in USDC on Base.
This PR adds the foundation for monetizing supermodeltools/mcp's API endpoints. We found 3 endpoints in your README that agents could pay to access.
Why agents would pay for supermodeltools/mcp
Each of these capabilities becomes a pay-per-call endpoint that AI agents discover and pay for automatically:
With x402, every feature above is instantly monetizable. Agents on Claude, Cursor, and any MCP client can discover and pay for access via 402.bot.
What's included
.well-known/x402.jsonx402-middleware-example.ts402 Payment Requiredand verifies paymentsHow it works
Settlement is instant. No intermediary holds funds. Revenue goes directly to your wallet.
What you'd earn
~$450/mo projected (3 endpoints × ~150 agent calls/mo × $0.01)
To activate
YOUR_WALLET_ADDRESSin.well-known/x402.jsonwith your Base walletx402-middleware-example.ts)Your endpoints will automatically appear in Claude, Cursor, and any MCP-compatible agent via the 402.bot MCP server.
Live demo
See how supermodeltools/mcp works on the x402 network ->
Links
This PR was opened by 402.bot. x402 is an open protocol - you keep 100% of revenue. We just route agents to providers. If this isn't relevant, feel free to close.
Summary by CodeRabbit
New Features
Documentation