DEV Community: Prakhar Gupta

How AI agents become your customers — lessons from shipping 17 paid MCP servers

Prakhar Gupta — Thu, 11 Jun 2026 10:25:53 +0000

Cross-post to dev.to, Hashnode, Medium.

Cover image suggestion: split-screen — left side a human customer support ticket, right side an AI agent API call. Title overlay.

The premise

For most of SaaS history, the buyer was a human. They visited a marketing page, signed up, entered a credit card. The product was built for human ergonomics — pretty dashboards, helpful onboarding emails, account managers for the bigger checks.

That assumption is breaking. Increasingly the entity calling your API isn't a developer integrating your product into their app. It's an autonomous agent (Claude, GPT, an internal LLM) being asked to use your tool mid-conversation, often by an end user the LLM has never seen and whose company has never heard of yours.

I shipped 17 MCP (Model Context Protocol) servers over the last few weeks. MCPs are tool servers that AI agents call to fetch data or take actions. By definition, the consumer is not a human — it's a language model. After weeks of designing those tool surfaces and watching usage trickle in, here's what's different.

What changes when your customer is an agent

1. The agent reads your docs before every call

Humans skim docs once, screenshot the SDK example, never come back. Agents re-read your tool descriptions on every conversation — because that's literally what the MCP spec does. Every connection includes a tools/list call that returns each tool's name, description, and parameter schema.

This means your tool description is the user manual every single time. There's no "the user read the README." There's only the description you handed to the agent at session start.

Practical implication: spend disproportionate effort on tool descriptions. The right description tells the LLM:

What the tool does (1 sentence)
When to use it vs other tools (this is the critical part — LLMs route badly when descriptions overlap)
What the parameters mean in plain English
What the return shape will look like

I rewrote SEC EDGAR's edgar_read_filing description four times. Version 1: "Reads an SEC filing." Useless. Version 4: "Returns the full text of a specific SEC filing identified by its accession number. Use after edgar_search_filings returns candidates. For 8-K item-specific extraction, use edgar_get_8k instead. Pass section='risk_factors' to extract just risk factor disclosures from 10-Ks."

The fourth version reduced misrouted calls (LLM calling read_filing when it should have called get_8k) by roughly half in my own test traces.

2. Errors must be actionable to the model, not just the human

When a human gets a 429 error, they read the docs and back off. When an agent gets a 429, it's about to retry with the exact same payload unless your error tells it not to.

The error responses an agent sees should answer: "What should I do now to make this succeed?" Examples that work:

"Rate limit reached. The free tier allows 100 calls/month per IP. To continue, get an API key at https://sec-edgar-mcp.atlasword.workers.dev/upgrade and pass it as Authorization: Bearer <key>."
"Filing not found. The accession number must be in format 0001193125-23-123456. Use edgar_search_filings to find valid accession numbers first."

Bad errors:

"Unauthorized"
"Bad request"
"Quota exceeded"

The good versions are longer. That's fine. The agent is reading them with full attention; the human will never see them unless they're debugging.

3. Pricing must be transparent to the model, not just the website

If your pricing is "$9/mo" on a marketing page, the agent doesn't know that. The agent knows what you returned in the last tools/list response. So you have to encode the relevant facts about pricing into the tool metadata or into the error responses.

I include a tool called <product>_get_pricing on most of my MCPs. It returns the current tier structure as JSON. The agent calls it once and now it knows what to recommend to the end user when they hit the free tier limit. Without that, the agent will hallucinate a price or just say "you should upgrade" with no actionable detail.

4. The conversion funnel collapses to one step

For human SaaS, the funnel is: visit site → sign up → enter card → use product → maybe upgrade.

For agent SaaS, the funnel is: end user asks a question → agent calls your tool → either succeeds within free tier, or returns an upgrade error with a direct upgrade URL.

There's no "sign up first" step. There can't be — the agent has no email, no payment method, no concept of an account. The only way conversion happens is if your upgrade flow is callable as a single URL the agent shows the human.

Concretely: my upgrade URL takes a Stripe Checkout that returns a usable API key the moment payment clears. No account creation step. No email verification. The buyer is the human supervising the agent, and that human just wants the agent to keep working. Adding any friction kills conversion.

5. Your value prop is now LLM-shaped

When the buyer was a human developer, "we have the best Python SDK" was a value prop. When the buyer is an LLM, it isn't. The LLM doesn't care about your SDK.

What the LLM cares about (per my error-trace analysis):

Latency. The agent will time out at ~10s. Anything that takes >5s gets retried, which hurts your rate limits and the user's experience.
Determinism. Tools that return slightly different data for the same inputs cause the agent to lose confidence in the result and re-ask.
Composability. Tools that pipe cleanly into other tools (output type matches input type of the next likely tool) get used more. Tools that require the agent to do data shape conversion get used less.
Description quality (see point 1).

This is a different value prop than "great DX for developers." Your README is now an artifact for SEO and human onboarding. Your tool description is the actual product surface.

6. The "growth loop" is agent-to-agent

Here's the unexpected one. Once an agent (let's say Claude) has used your tool successfully in a conversation, the end user is more likely to use Claude for that kind of question in the future. Claude's value to that user has gone up because of your tool.

This means the marketing flywheel is partly: "agents that have used your tool deliver better answers, which makes the agent platform stickier, which makes the platform invest more in MCP infrastructure, which makes more agents discover your tool."

You're not just selling to humans through agents. You're indirectly improving the agent's market position, and the agent platforms (Anthropic, OpenAI, Cursor) have an incentive to surface tools that make their agents look good.

I'm watching for this empirically. Smithery, Glama, mcp.so — these are agent-shopping surfaces. They're not for humans to browse. They're for agent platforms to scrape and for agents themselves to discover tools at session-init time.

7. Pricing can be much lower than human SaaS

Human SaaS minimum viable price is roughly $9-19/mo because the human's attention to evaluate, sign up, and integrate is the dominant cost. Below that, the time isn't worth it.

Agent SaaS has no such floor. The agent has no attention cost. Conversion happens in one second when the human clicks "upgrade." This means $5/mo or even $1/mo can be viable for high-frequency low-value tools.

My unit-converter MCP is $5/mo for the same reason a vending machine is $1 a coke and not $19/mo. The friction is zero, so the price clears at a level that would be impossible for a human-evaluated SaaS.

Whether $1-5/mo MCPs are a real market is testable now. My bet is yes, for utility surfaces.

8. What I still don't know

How do you market to agents? You don't, directly. You market to agent platforms (get listed in directories) and to the humans who choose which tools their agents have access to. But the relative weight of those is unclear.
How do you handle abuse? An agent doesn't have a credit history. If a bad actor uses an agent to hammer your free tier, the agent's reputation isn't on the line; only the underlying IP is. IP blocking helps but isn't sufficient.
How do you build retention? With humans, you send re-engagement emails. With agents, there's no email. The agent uses your tool again only if the user asks a question for which your tool is the best fit. So retention is really "stay top-of-mind in the tool descriptions of the directories agents read."

What I'd tell anyone shipping for AI agents

Treat your tool description like it's the product page. Because for the agent, it is.
Make errors actionable. The agent reads every byte.
Single-URL upgrade. No account creation. Friction kills.
Optimize for latency and determinism, not feature surface. The LLM cares about reliability, not bells.
Ship a pricing tool. Let the agent introspect what to recommend on upgrade prompts.
List on every directory. Discovery is agent-platform-driven, and listings are crawled by agents at session start.
Price lower than you'd dare for humans. $1-5/mo is a real wedge for utility tools.

Resources

The 17 MCP servers I built: https://mcp-hub.atlasword.workers.dev/
Source for all of them (MIT): https://github.com/guptaprakhariitr
Model Context Protocol spec: https://modelcontextprotocol.io/

Honest disclaimer: zero customers as of this writing. Everything above is from designing the surface and watching test traces, not from years of MRR data. If you ship MCP-based products yourself and your data disagrees with any of this, I'd love to hear it.

Building an 18-product MCP portfolio in a few weeks

Prakhar Gupta — Thu, 11 Jun 2026 10:25:51 +0000

Cross-post to dev.to, Hashnode, Medium. Recommended canonical URL: your personal blog if you have one, otherwise dev.to.

Cover image suggestion: a screenshot of the hub homepage with the 17 product cards visible.

TL;DR

Over a few weeks I built 17 customer-facing Model Context Protocol (MCP) servers plus an analytics service and a master hub. Each one is a thin Cloudflare Worker that wraps a free public data source into a tool surface AI agents can call. Source is MIT, hosted on Cloudflare's free tier, with an anonymous free tier on every product. Hub: https://mcp-hub.atlasword.workers.dev/

This post is about the architecture, the economics, and the parts that are harder than they look.

Why a portfolio of 17 instead of one polished product

The conventional indie-hacker advice is: pick one wedge, go deep, become the best-in-class for that one thing. I deliberately did the opposite. Three reasons.

1. The marginal cost of an additional MCP is small. Once you have the template — Worker entrypoint, KV cache, quota counter, Stripe webhook, OpenAPI generator, smithery.yaml, server.json, npm wrapper — the only product-specific code is the upstream API client and the tool definitions. For most public APIs that's 200-500 lines of TypeScript.

2. The marginal cost of an additional listing is also small. Submitting to Smithery, Glama, mcp.so, the official registry, awesome-mcp lists, etc., is per-product effort. But you can template the listing content too. So 17 listings on 8 directories is 136 submissions — but the marginal one is two minutes once the script is written.

3. I genuinely don't know which buyer will show up first. A portfolio is a hedge against being wrong about the buyer. If SEC EDGAR doesn't take off but GST validator does, fine — I follow the signal. Building one wedge would have locked me into a guess about the buyer.

That's the thesis. Whether it's right is testable, not arguable.

The architecture

Each product is a single Cloudflare Worker. The diagram is:

Claude / Cursor / Cline / any MCP-compatible agent
                |
                | MCP-over-HTTP (JSON-RPC 2.0, POST /mcp)
                v
            Cloudflare Worker
               /          \
              /            \
       KV: usage         KV: cache
       (quota counter)   (upstream API responses)
              \            /
               \          /
                v        v
            Upstream public API
        (SEC EDGAR, openFDA, GDELT, ...)

Per worker:

src/index.ts — MCP server, routes /mcp, /openapi.json, /llms.txt, /upgrade
src/client.ts — upstream API client with retries
src/tools.ts — MCP tool definitions (the part that takes the longest)
src/usage.ts — KV-backed quota counter (shared across all 17, copy-pasted)
src/stripe.ts — Stripe webhook handler (shared across all 17, copy-pasted)

Total ~500-1500 LOC TypeScript per product. The shared code is roughly 300 LOC across all products.

The MCP-over-HTTP transport

A lot of MCP servers in the wild are stdio-only npm packages. That works but it's clunky — every server you add to Claude Desktop spawns a child process at startup, every request requires JSON serialization over a pipe, and it's hard for non-desktop clients to use them.

MCP-over-HTTP is just JSON-RPC 2.0 over POST. The endpoint accepts:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "edgar_search_filings",
    "arguments": { "cik": "0000320193", "form": "10-K", "limit": 3 }
  }
}

And returns:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      { "type": "text", "text": "Found 3 10-K filings for AAPL: ..." }
    ]
  }
}

You can curl this. You can call it from any HTTP client. Claude Desktop's HTTP MCP support is recent; Cursor, Cline, and most newer agents speak it natively. For desktop fallback, I ship an npm wrapper (@insnapsprakhar/<slug>-mcp) that bridges stdio → HTTP.

Quota metering on KV

Workers KV is eventually consistent, which sounds scary for a counter but is fine in practice. Burst tolerance > strict correctness.

async function incrementUsage(env: Env, key: string): Promise<number> {
  const current = await env.USAGE.get(key)
  const next = (current ? parseInt(current) : 0) + 1
  await env.USAGE.put(key, next.toString(), { expirationTtl: 60 * 60 * 24 * 31 })
  return next
}

async function checkQuota(env: Env, apiKey: string | null, ip: string): Promise<QuotaStatus> {
  const key = apiKey ?? `anon:${ip}`
  const month = new Date().toISOString().slice(0, 7)
  const usage = await incrementUsage(env, `usage:${key}:${month}`)
  const limit = apiKey ? lookupTierLimit(apiKey) : 100  // anon free tier
  return { used: usage, limit, blocked: usage > limit }
}

That's the whole metering surface. ~30 LOC. No D1, no Postgres, no Redis. The race condition during a burst is a few extra calls beyond the limit, which is a fine user experience for a free tier.

The hardest part: tool surface design

The architecture took maybe 3 weeks of figuring out. The shipping took weeks. The hard part was — and still is — deciding what the right 5-10 MCP tools per data source are.

A tool that's too generic (edgar_query, takes any URL) gives the LLM no leverage; it has to construct the URL itself. A tool that's too narrow (edgar_get_apple_10k, one company) doesn't compose. The right surface is somewhere in between, and depends on what kinds of questions the agent is being asked.

For SEC EDGAR I settled on:

edgar_search_filings(cik?, form_type?, date_from?, date_to?, limit?)
edgar_read_filing(accession_number, section?)
edgar_get_facts(cik, concept?)
edgar_get_8k(cik, item_number?, since?)
edgar_get_company(query) — name/ticker → CIK
edgar_get_insider_trades(cik|name, since?)

Six tools. Each one composes with the others — you call edgar_get_company to get a CIK, then edgar_search_filings, then edgar_read_filing. The tools intentionally don't pre-summarize because LLMs are better at that than I am.

I am genuinely uncertain whether 6 is the right number for every product. Two of the simpler products (gst-validator, hsn-classifier) have 3 tools each and feel right. The more complex ones (indian-regulatory, indic-normalize) have 9-12 and feel like they're at the upper limit before the LLM starts misrouting.

Distribution: harder than the code

There are at least 8 directories where you can list an MCP:

Directory	Mechanism	Time per submission
Official `modelcontextprotocol/registry`	`mcp-publisher` CLI + GitHub OIDC	~2 min (after CI setup)
Smithery	smithery.yaml in repo, auto-crawled	~0 min (passive)
Glama	Auto-crawls awesome-mcp-servers	~0 min (passive after PR merges)
mcp.so	GitHub issue or web form	~5 min per product
PulseMCP	Web form	~5 min per product
MCPMarket	Web form / OAuth	~5 min per product
Cursor MCP gallery	PR to Cursor's repo	varies
punkpeye/awesome-mcp-servers	PR	once for all 17

Even with templating, 17 products × 8 directories = 136 submissions. Not all are programmatic. The directories that auto-crawl (Smithery, Glama) you get for free once your repo metadata is right. The ones that require manual submission are the bottleneck, and the way I've handled it is to script-generate the issue/PR bodies and submit in batches.

Economics

Cloudflare Workers free tier: 100k requests/day, KV reads 100k/day free, writes 1k/day. The paid plan is $5/mo and would cover the entire 17-product directory at meaningful scale.

Per product:

Free tier: ~100 calls/month/IP, anonymous
$5-9/mo paid tier: 5k-10k calls/month
$19-29/mo: premium tools + higher quota
$79+ tiers: bulk endpoints, team accounts

Break-even per product is roughly one paying customer at $9/mo (covers shared Stripe + Worker bundle costs + my time at $50/hr against the ~6h spent). Across the portfolio, break-even is ~10 paying customers total. Today: zero. This is launch day, not a postmortem.

What I'd do differently

Build the first 3 hard, validate distribution, then template. I built the first 8 in parallel before realizing the distribution flow needed work. Should have shipped 1-2-3 sequentially with full distribution per product, then parallelized.
Stripe on Day 0, not Day 5. I delayed Stripe until product 5 thinking free tier would generate signups first. Free tier generates calls, not signups. Conversion happens via in-app upgrade prompts that need a payment surface from the start.
Pick a sharper buyer for at least one product. "Anyone who wants SEC data" is not a buyer. "Equity research analysts at funds under $500M AUM who pay $50+/mo for Bloomberg-alternative tools" is a buyer. I deliberately stayed generic on most products as a hedge; for at least one, I should have been narrow.

Code

All 17 products are MIT, public on GitHub: https://github.com/guptaprakhariitr

Hub: https://mcp-hub.atlasword.workers.dev/

If you want to fork the pattern — it's the same Worker template across all of them, with the upstream client swapped — you can. The _template directory under no-grav/products/ has the bones.

Happy to answer questions in the comments — especially about Workers KV economics, the metering flow, or the tool-surface design choices.

If you found this useful, the easiest way to support is to try one of the 17 servers with your AI agent and tell me where the tool definitions are wrong. That's the part I'm least confident on.