DEV Community

Cover image for I made Korean government data agent-payable with MCP and x402 — here's what actually happened
Yoon
Yoon

Posted on

I made Korean government data agent-payable with MCP and x402 — here's what actually happened

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)

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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 (2)

Collapse
 
rivendesk profile image
Riven Desk

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.

Collapse
 
micheypico profile image
Micheal Heypico

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.