我把 API 优化给 AI Agent 而非人类：一周数据说明了什么

Yoon Yoon Yoon Follow Sep 16 I made Korean government data agent-payable with MCP and x402 — here's what actually happened #ai #mcp #webdev #cryptocurrency Comments 6 comments 5 min read Two weeks ago I put a paid MCP server online: Korean business verification, priced per call in USDC over x402. I wrote up the build here. This is the follow-up nobody writes — the part where you check whether anyone actually showed up. Short version: 23,980 requests in seven days, and two of them were real. Here's what I learned from the gap between those two numbers. The experiment One hypothesis, one number to falsify it. Hypothesis: if agents can discover a priced API and pay for it autonomously, some of them will. Success bar: 20 real tool calls in the first week after launch. I wrote that number down before launching, which turned out to be the single most useful thing I did. Metric Day 0 Week 1 Requests (7 days) ~8,700 23,980 Real external tool calls 0 2 Third-party payments 0 0 Requests nearly tripled. Real usage went from zero to two. Every payment in my receiving wallet is still one I made myself. Breaking the 41 logged tool calls down by origin: 7 were my own indexing payments, 32 were crawlers requesting the literal path template from the discovery catalog (/v1/business/:brno/status — they call the placeholder, not a real number), and 2 were actual external calls. Both on the same day, hours apart, then nothing for six days. So: missed the bar by a factor of ten. The traffic wasn't fake. It just wasn't people. After getting listed in the x402 Bazaar, a new class of visitor showed up: kkj-x402-trust-index (its user agent says it verifies Bazaar-listed x402 resources), allow402-quote, x402-observer, x402-census-probe, plus the usual liveness bots that announce "never invokes tools" in their UA string. An ecosystem of watchers has grown up around agent payments, and it found me within days. There's something genuinely encouraging in that: the infrastructure works. Discovery works. Listings propagate. Scanners verify you. What hasn't arrived is the buyer. The thing I'd fix first if I started over Here's the mistake I only saw when I stopped looking at request counts and started reading connection logs. 69 handshakes. 17 curl calls. 39 from python-requests. People connected. Almost none of them executed a tool. My server takes a 10-digit Korean business registration number as input. But if you're an agent outside Korea evaluating a supplier, what you have is a name — "Hanil Trading Co., Ltd" — not a registration number. That number lives on invoices and contracts, which means by the time you can use my API, you already have a relationship with the company. I built a tool that requires you to already have the thing you came looking for. That's not a discovery problem or a pricing problem. It's the shape of the product. No amount of catalog optimization helps when the first input field is one your user can't fill in. Three things I'd tell anyone shipping a priced API for agents Start from the agent's task, not your data. "Look up a registration number" is a data endpoint. "Decide whether to transact with this supplier" is a task. Agents arrive with tasks. If your endpoint sits in the middle of one, you have to own the entrance too, or someone else's tool will. A free tier is a discovery liability, not just a pricing decision. The Bazaar validator checks that an unpaid request returns 402. My friendly free tier returned a cheerful 200, so the catalog concluded the resource wasn't payable and skipped it entirely. Default-paid with opt-in free (?free=1) fixed it — and closed the hole where rotating IPs got unlimited free calls. Catalogs index routes, not servers, and only after a payment settles on that route. Each of my three endpoints stayed invisible until I'd paid for that specific one myself. Worse, all three had near-identical descriptions, so every query surfaced the same route. Rewriting them by intent — status for "is this company still operating", batch for "screen this supplier list", verify for "KYB identity match" — made queries that never mention Korea start returning the right one. Highest-leverage hour I spent all month. Where the next two weeks go Not into more distribution. Two things: An entrance. Resolve a company name to a registration number, so an agent can start from what it actually has. Harder than it sounds — name matching is fuzzy, so the honest design returns ranked candidates with evidence, not one confident answer. Signals worth paying for. Debarment records, sanction history, status changes over time. One call that answers "should I transact with this company" instead of "does this number exist". Then I measure again the same way: number written down first, honest count after. If you're building something agent-facing and have run your own numbers, I'd like to compare. My suspicion is that a lot of us are shipping data endpoints into a market that only buys finished tasks — and that the distance between 23,980 and 2 is mostly the shape of what we built, not the size of the market.