← blog

Building an Agent Tool Marketplace from Zero — Lessons from Week 1

2026-02-28·8 min read·Hudson Taylor

Five days ago, Agent Bazaar was a database schema and a proxy route. Today it's a marketplace with 35 API endpoints, a public catalog, provider dashboards, consumer registration, signed receipts, dispute resolution, and an open billing spec. Here's what I learned building it.

The thesis: MCP servers can't make money

The Model Context Protocol is exploding. Thousands of MCP servers exist — weather APIs, code execution sandboxes, database connectors, web scrapers. But almost none of them generate revenue. The developers who built them have no way to get paid per-call.

Stripe doesn't handle sub-cent transactions. Building your own billing layer is a 2-4 week project minimum. Most MCP developers are solo builders who'd rather write code than implement metering infrastructure.

So we built it for them.

Lesson 1: The proxy is the product

The core of Agent Bazaar is a billing proxy. An AI agent calls our endpoint, we authenticate the request, check the consumer's balance, proxy the call to the provider's MCP server, meter the response, deduct the cost, and return the result. One HTTP call from the agent's perspective.

This is deceptively simple in concept and surprisingly complex in practice. You need: rate limiting per consumer, balance checking with race condition handling, timeout management, retry logic, error categorization, latency tracking, and receipt generation — all in the hot path of every single tool call.

Our proxy route is 305 lines of TypeScript. Every line matters.

Lesson 2: Trust is a feature, not a nice-to-have

AI agents make autonomous decisions about spending money. An agent calling a tool at $0.01/call sounds cheap until it's making 10,000 calls per day. That's $100/day with no human in the loop.

We built the Trust Layer because agents need cryptographic proof of what happened. Every tool call gets an HMAC-SHA256 signed receipt — the tool called, the input hash, the output hash, the cost, the latency. If something goes wrong, you can file a dispute against a specific receipt. If a provider's uptime drops below their SLA, it shows up in their trust score.

No other MCP billing solution has this. It's our moat.

Lesson 3: Open spec → defensible position

Counterintuitively, publishing our billing spec as MIT-licensed open source makes our position stronger, not weaker. Here's why:

Lesson 4: The 18% number

We charge 18% on paid tool calls. Here's how we arrived at that:

18% gives providers 82% of revenue while covering Stripe processing fees (~2.9%), infrastructure costs, and leaving margin for the platform. It's low enough that providers prefer us over building their own billing, and high enough to sustain the business.

Lesson 5: Ship the marketplace before you have sellers

Classic chicken-and-egg. You need providers to attract consumers, and consumers to attract providers. We solved this by:

  1. Building our own demo providers (BotWall3t, Deploy Rail) to seed the catalog
  2. Making the marketplace browsable even with seed data — it looks real because it is real
  3. Opening provider registration first — MCP developers can list their servers today and be ready when consumers arrive
  4. Reaching out directly to high-star MCP server maintainers on GitHub

What's next

We're 5 days in. The architecture is solid, the billing math works, the trust layer is live. Now we need:

If you maintain an MCP server and want to monetize it, register as a provider. Setup takes 5 minutes. The billing spec is open source.

We're building this in the open because the MCP ecosystem deserves transparent infrastructure, not walled gardens.

Links