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.
