led by Ryan Garver · Boise, Idaho Get Smart AI, led by Ryan Garver
Back to work

Design + build · 2026 · v1 · self-test passing

Competitor-Intel MCP

An MCP server that sells competitor data to AI agents instead of people.

zero Dependencies
Yelp · Places · Meta Official APIs
<5% MCP servers monetized
$ tools/list
> competitor_snapshot   reviews, rating, hours
> price_position        menu / service pricing
> ad_activity           Meta ad library pull
> report                one-call briefing (paid)
The tool surface an agent sees. Python stdlib only; JSON-RPC 2.0 over stdio.

AI agents can now find and call tools on their own through the Model Context Protocol. That is a new kind of distribution: an agent picks your tool because it works, not because you marketed it. There are roughly 13,000 public MCP servers today and fewer than 5% make any money. I wanted to find out whether a well-built one could, and to do it as a disciplined experiment rather than a hopeful guess.

The bet: sell to agents, not to people

The agent economy inverts the usual solo-founder problem. There is no audience to build, because the buyer is a program that discovers tools by capability. So the question is not "can I market this," it is "is the tool good enough that an agent would choose it, and can it charge per call." I picked a concrete job to test that: competitor intelligence on a local business.

What it does

It exposes a single tool, get_competitor_intel(business_name, location), that returns a structured report on a local business: its public reputation and any advertising signal. The data comes only from official APIs, Yelp Fusion, Google Places, and a best-effort Meta Ad Library lookup. Every response carries a _provenance block stating where the data came from and whether it used live keys or a mock fallback.

Architecture

The protocol layer and the data clients stay separate. It is written in plain Python with no dependencies, so there is no supply chain to worry about and it starts instantly.

AI agent ──MCP/JSON-RPC(stdio)──▶ server.py ──▶ intel.py ──▶ Yelp Fusion API
                                     │                     ├─▶ Google Places API
                                     │                     └─▶ Meta Ad Library API
                                     └─ _charge() ─▶ Apify pay-per-event billing

The decisions that separate sellable from toy

  • Official APIs only, even when it costs coverage. Google has no official ads-transparency API, so instead of authenticating and scraping it, I dropped that source. Scraping is the difference between something you could sell and something that breaks the first time a page changes its markup. Yelp and Places are the reliable core; Meta is best-effort.
  • Honest coverage labeling. Meta's API covers political ads fully but commercial ads only partially, so the payload says so. A consuming agent must not over-trust a null result, so the tool tells it where its own vision is limited.
  • Testable without secrets. Any missing key makes that source return realistic, clearly-flagged mock data, so the whole tool runs in a demo or a test with zero credentials and switches to live data the moment keys are set. The self-test is hermetic by design.
  • Packaged to earn. It ships as an Apify pay-per-event Actor, with the billing hook already wired, rather than a subscription, because agents care about capability per call, not a monthly plan.

How I verified it

The self-test drives the real protocol, initialize, tools/list, tools/call, over stdio and asserts the behavior, and it passes with no API keys at all. The mock data returns in the same normalized shape as live data, so adding keys is the only change between demo and production. The engineering is done and checkable; what is unproven is demand.

Honest results, on purpose

I have not proven anyone will pay for this, and I am not pretending otherwise. I funded it as a cheap, instrumented probe, under $50, with a hard kill gate: at least one paid call from someone who is not me, inside 30 days, or the revenue experiment is shelved. If it fails that gate, the engineering artifact still stands and the revenue line does not. Falsifiable, with the failure condition written down first.

Why I point to this one

It shows two things at once: that I can implement a protocol correctly from the wire up, with deliberate legal and ethical boundaries in how data is sourced, and that I test a business idea the way I test code, with a probe and a kill gate instead of optimism. That combination, real engineering plus honest validation, is exactly what AI product work needs.