TL;DR: I built a remote MCP server that lets any AI agent verify Korean businesses using official National Tax Service data — and charge for it per call in USDC via x402. It works end-to-end: here's the first on-chain payment — an agent hit a 402, paid $0.02, and got real government data back, no human in the loop. It's now listed on the x402 Bazaar, Coinbase's discovery catalog for agent-payable APIs, where it currently ranks at the top for "korean business registration verification" — agents find it by searching, not by reading docs. Along the way I learned that directory listings get you 1,250 bot requests a day, that a free tier can silently disqualify you from payment marketplaces, and a few other things nobody tells you.
Why Korean business data
If you're a procurement or compliance agent outside Korea and you need to answer "is this Korean supplier a real, active company?", you're stuck. The official data exists — Korea's National Tax Service (NTS) runs a free public API — but it sits behind a Korean-language portal, phone-verification signup, and API key issuance that an autonomous agent simply cannot do. An agent can't pass Korean SMS verification. It can't read the docs. It gives up or hallucinates.
That gap is the product: Korea Business Verify (KBV) — one URL, no signup, no API key. Ask it about a 10-digit business registration number and get back active/suspended/closed status, tax type, and KYB identity matching, in clean English JSON, straight from NTS. Up to 100 companies in a single batch call.
Server: https://kbv-server-f7vfitmlkq-du.a.run.app/mcp (Streamable HTTP)
Source: https://github.com/Wonderfulian/kbv-server (MIT)
Free: 10 calls/day. Beyond that: $0.02 per status check, $0.05 per identity verification, $0.02/company for batch — paid in USDC on Base via x402.
The stack, briefly
NTS public API → TypeScript + official MCP SDK (+ Express for REST) → Cloud Run (scale-to-zero, so idle cost ≈ $0) → x402 v2 (@x402/express, @x402/core, @x402/evm) → Coinbase CDP facilitator → USDC on Base. The server never touches a private key — it only knows the receiving address. Settlement verification is the facilitator's job.
One paid call, end to end. The agent never talks to a human — it discovers the price, signs the payment, and gets the data.
Total cash spent to build, deploy, and verify all of this: about $3 (one exchange transfer fee plus test payments to myself).
What nobody tells you (the honest part)
Directory traffic is a mirage. After listing on the official MCP Registry, Glama, and Smithery, my server started receiving ~1,250 requests a day. Exciting! Except a User-Agent breakdown showed nearly all of it was health-check and security-scanner bots — some literally announce "never invokes tools" in their UA string. Actual external tool calls in the first week: effectively zero. If you're building an MCP server: request count is not a popularity metric. Count tools/call, nothing else.
Your free tier can disqualify you from payment marketplaces. x402 has a discovery marketplace (the Bazaar) where paying agents find priced resources. Its validator checks that an unpaid request returns HTTP 402. My server had a friendly free tier — 10 calls/day per IP — so the validator got a free 200 and concluded the resource wasn't payable. The free tier also meant anyone rotating IPs could scrape indefinitely. Fix: REST now returns 402 by default, and the free tier became opt-in via ?free=1. Default-paid, intentionally-free turns out to be the right default for the agent economy.
Everything is three months newer than the docs. The MCP registry rejected my first two publishes because the server.json schema had changed weeks earlier. x402 moved to v2 (new headers, new packages) while most tutorials still show v1. Cloud Run's URL took four hours to propagate on a fresh project. None of these are hard problems — but every one of them cost hours, and none of them appeared in any guide. Budget for the ecosystem shifting under your feet.
The "receiving crypto without an exchange account" part is easier than expected. I'm in Korea, where Coinbase's retail exchange isn't available. Didn't matter: receiving x402 payments needs only a wallet address. The facilitator handles verification. My keys live in MetaMask, never on the server.
Independent scanners will find you before customers do. Within days, a trust-scoring service (M8ven) had auto-indexed the server, run static analysis (clean: no credential exfiltration, no obfuscation), and emailed me one legitimate fix — my tools were missing the four MCP annotation hints (readOnlyHint etc.), which OpenAI's directory requires. The agent ecosystem is growing an immune system faster than it's growing customers. I claimed the listing and fixed the hints the same day.
Discovery catalogs index routes, not servers — and only after someone pays. The x402 Bazaar only indexed the exact route I had actually settled a payment on. My other two endpoints stayed invisible until I paid for each of them myself. And the indexing happened the instant I paid — but the public listing lagged by days, long enough that I concluded I'd failed when I had actually succeeded. If you're doing this: pay once per route, then wait before you panic.
Where this stands
KBV is brand new — I completed the end-to-end mainnet payment verification just this week, and this post is its public debut. It's discoverable on the x402 Bazaar with full input/output schemas, so a paying agent can find it and call it correctly without any documentation. The x402 buyer pool is real but still early — this is a land-grab phase, not a gold rush. What I have is a verified, monetized, trust-scored piece of infrastructure that cost ~$3 and a few weekends, sitting on a corner (Korean official data, agent-payable, zero-setup) that nobody else occupies yet. When agentic procurement becomes normal, the pipes are already laid.
Try it
Add the URL as a custom connector in Claude or ChatGPT and ask it to verify a Korean business — Samsung Electronics is 124-81-00998 if you need a test number. First 10 calls a day are free (?free=1 on REST). Code, schemas, and pricing are in the repo. I'd genuinely love to hear what breaks.
Built by a solo non-engineer in Seoul with heavy help from Claude (design/review in chat, implementation via Claude Code). Happy to answer anything about MCP monetization, x402 v2, or wrapping government data for agents.
Top comments (7)
The distribution lessons are as useful as the payment demo. “Directories index routes, not servers” is a sharp distinction—especially when a successful paid call is what creates the signal that gets you discovered. I also like the honesty about scanners arriving before customers; for an agent-facing API, that makes reproducible verification and clear rate limits part of the product, not just ops. I’d be curious whether you plan to publish a small set of deterministic test cases so agents can validate KBV integrations without spending on every probe.
Thanks, and good question. Right now the free tier covers it partly — append ?free=1 to the REST endpoints and you get 10 calls a day without paying, and MCP calls use the free tier automatically. But you're right that it's not ideal for integration testing, since those calls hit the live NTS API and eat the daily quota.
I'm planning to add a small set of fixed test numbers that always return the same responses (active, closed, not registered, identity mismatch) and never count against the free tier. That way an agent can validate its whole flow, including error handling, before spending anything. I'll reply here when it's live.
It's live now. 124-81-00998 (Samsung Electronics) is exempt from the free-tier quota across every endpoint and MCP tool — mix it into a batch and only that number is excluded from billing. It returns real NTS data rather than a canned fixture, so you're validating the actual response shape rather than a mock. Documented in the README pricing section and in /llms.txt.
I went with one known-good number rather than the full set of fixtures I described above, since the error paths (invalid format, not registered, identity mismatch) are all deterministic already and don't consume quota the way a successful lookup does.
Thanks for the nudge — implementing it also surfaced a billing inconsistency where the test number was exempt from the quota but was still being settled.
Nice writeup. The free-tier/marketplace issue is one of those things you can only discover by actually shipping something. Your conclusion that default-paid with opt-in free is the right pattern seems exactly right.
The server-not-holding-a-key architecture you describe is worth calling out separately. It turns the server into a permissioned relay rather than a custodian. That distinction matters a lot when you think about audit trails and key revocation. It's the same hosted-authorization design that CAI uses for agent payment and identity.
Glad KBV got onto the x402 Bazaar. The listing delay is rough, but having mainnet verification working start-to-finish is the real achievement.
Agreed, that's the right line to draw. For a $0.02 lookup, full agent autonomy is fine because the downside of a bad call is two cents. For anything where the price climbs, a separate authorization step makes a lot more sense than trusting the agent's runtime with the key. KBV's batch route is already the edge case here, since it can go up to $2.00 per call, so it's a question I'll need to think about more.
Useful post, especially the free tier accidentally blocking your Bazaar listing. That's the kind of gotcha that's impossible to learn without shipping. Default-paid as the right default for agent APIs.
The x402 model works well for sub-cent calls where full agent autonomy is the right tradeoff. The interesting question is what happens when the transaction value climbs high enough that you want a confirmation step before the agent signs. There's a hosted action pattern emerging where the tool proposes a payment and a separate context authorizes it, keeping the signing key out of the agent's runtime entirely. Same problem of making agents able to pay, different trust model for different price points.
End-to-end mainnet payments on $3 and a few weekends is a solid signal that the infrastructure is getting real. Thanks for sharing the honest numbers.
This matches what we see operating a model-routing layer (32 models, one key at heypico.ai): the deterministic scaffolding around the LLM is what makes multi-model setups viable. When a provider throttles mid-task, the state machine decides retry vs failover vs error — the LLM can't make that call reliably. Debugging a 'flaky agent' is usually debugging a missing state machine around a fine model.