Back in Part 1 I split the AI-search problem into two games, and then spent three posts on only one of them. Time to pay off the other.
The two games, revisited
Game A is content citation: an AI answer engine pulls a sentence from your page, quotes it, and links back. Parts 2 through 4 were mostly Game A — front-load the answer, harden the schema so it doesn't drift, get the crawler and indexing plumbing right, and measure the referral traffic the dashboard hides from you. That game is winnable, and it's most of what "GEO" means today.
Game B is tool invocation. It's a different thing entirely. When an agent needs to flip a coin, generate a strong password, convert 1994 to Roman numerals, or work out what grade a 43/60 test is — the win isn't being quoted. It's being the tool the agent actually calls. Nobody reads your coin-flip page in that flow. Something reaches out, executes a function, and takes the result.
And here's the thing I keep coming back to: a fast, single-purpose, no-signup, stateless tool has a structural advantage in Game B that it never had in Game A. In content citation you're fighting decade-old domains with backlink moats. In tool invocation you're competing against ad-wall SPAs that need three round-trips, a cookie consent modal, and a login before they'll flip a coin. An agent will pick the endpoint that returns clean JSON in one round-trip, every single time.
Why a tools site is uniquely positioned
Most of what we've built is, quietly, a library of pure functions. Coin flip. Dice roller. Password generator. Roman numeral converter. Grade calculators. Unit conversions. These are things an agent would genuinely rather call than read — there's no prose worth quoting, just an input and a deterministic output.
That's a shape almost nobody in the free-tools space has deliberately positioned for. Expose those functions as a documented JSON API — say GET /api/tools/coin-flip returning {"result": "heads"} — and you've turned a web page into a callable capability. Then take the next step: wrap the whole set as an MCP server. MCP (Model Context Protocol) is the emerging open standard by which agents and IDEs discover and call external tools without bespoke glue for each one. An agent adds one MCP endpoint and gets the entire toolbox — every function we've ever shipped, self-describing, in a single install.
Breadth is the differentiator there. One competitor might expose a coin flip. Nobody's exposing dozens of documented pure functions behind one protocol handshake.
The monetization ladder
I want to be honest up front: none of these earn a cent before there's demand. But it's worth knowing the rungs, roughly in order of fit for what we are:
- Attribution-first free tier — the on-ramp. Every API response carries a
"powered_by": "https://lans.cloud"link. It doesn't bill anyone; it monetizes indirectly, by feeding branded traffic back to the ad-supported pages. When an agent cites "flipped via lans.cloud", some humans follow the link. This is where you start, because it's free to run and it compounds. - Freemium API keys. Free tier is IP-rate-limited; paid keys raise the ceiling and add an SLA. Standard, boring, works.
- Usage-metered billing for the high-call-volume pure functions, where someone's automation is hammering an endpoint thousands of times a day and would happily pay per call rather than self-host.
- The MCP server as a product. One install, all the tools. You're not selling a coin flip — you're selling never having to find and wire up sixty small utilities. Breadth is the pitch.
- Affiliate inside the answer, but only where it's genuinely useful — a crochet-stitch calculator that surfaces a yarn-retailer link is helping; a password generator that does is spam. The bar is "would a human thank me for this link."
Why we gated it instead of building it now
Here's the disciplined part, and honestly the part I'm proudest of resisting.
Building an invocation surface blind is the single cleanest way to burn real engineering effort on maybe-nothing. It's seductive — MCP is new and shiny, the architecture is fun to design, and it feels like the future. Which is exactly why it's dangerous. You can spend a month on a beautiful API that zero agents ever call, and you'd have no way of knowing you were wrong until it was built.
So we didn't build it. We gated it on a demand signal. The trigger is one of three things:
- AI-referral traffic actually showing up in the logs — the exact signal Part 4 is about instrumenting. If agents are already citing us, agents are in the neighborhood.
- An inbound request — someone emailing to ask "do you have an API?"
- A concrete, named opportunity we can point at.
When one of those fires, the first move isn't "build the platform." It's a spike: take two or three pure-function tools, expose them as a stateless, read-only, no-auth JSON API with attribution baked in, ship it, and measure whether anything picks it up. Only if something does do we build the MCP server and broaden the surface. Until then, AdSense stays the near-term revenue engine. This whole track is optionality and moat — not this quarter's income, and I won't pretend otherwise.
Why the spike is cheap and safe
The reason gating works here — rather than being an excuse to procrastinate — is that the spike is genuinely cheap to run when the gate opens. Most of our tools are already stateless, read-only, and hold no PII. There's nothing to protect and nothing to leak. The free tier's abuse surface is a rounding error: an IP rate-limit is the entire security model, because the worst an abuser can do is flip a lot of coins. No auth to build, no user data to guard, no session state to reason about. That's what makes "wait for the signal, then spike in a weekend" a real plan and not a stalling tactic.
Closing the series
So that's the arc. Part 1 drew the map — theory, and the two games. Part 2 was on-page: front-loaded answers and schema that doesn't drift. Part 3 was plumbing: llms.txt and the agentic web. Part 4 was measurement: seeing the traffic your analytics dashboard structurally can't. And this one, Part 5, is the moat — becoming a capability agents run, not just a page they quote.
The throughline is this. For a tools site, GEO is winnable on the long tail precisely by making each page maximally quotable — that's the near-term, do-it-now work. The deeper, slower play is becoming an invocable capability, which is where the durable advantage lives if the agentic web plays out the way it looks like it will.
But I'll end where I always end, because it's true and the hype cycle keeps trying to make people forget it: none of this beats the fundamentals. Authority — real backlinks from real sites. Indexing — Google actually crawling and keeping your pages. And time. GEO is a multiplier on those, not a substitute. Build the quotable pages, instrument the measurement, keep the invocation moat as gated optionality — and then go earn the backlinks and wait. There is no shortcut around the boring parts. There never is.