The PM's Guide to Agent Distribution: MCP Servers, CLIs, and AGENTS.md

Stripe, Cloudflare, Linear, and 7 others already shipped. Audit template, PRD, and Claude Code sprint included.

Your product’s next million users won’t have eyes.

They won’t visit your website, sit through your onboarding, or read your changelog. They’ll be AI agents, autonomous software that discovers, evaluates, and integrates tools programmatically.

Quote me on this:

If your product cannot be parsed, authenticated, and executed by an agent, you are invisible in the fastest-growing software channel.

It sounds futuristic. It isn’t. Stripe, Cloudflare, Shopify, GitHub, Asana, Zapier, and others have already shipped agent-facing surfaces.

Andrej Karpathy put it bluntly last week: “It’s 2026. Build. For. Agents.”

The post named something product teams have been slow to act on: the distribution channel is shifting from human interfaces to agent interfaces.

---

Today’s Post

This is the most practical guide I could write on how to own this shift as a PM:

1. The 5 Distribution Channels - and Why #5 Changes Everything

2. The Agent-Accessible Product Stack

3. The PM’s Role in Agent Distribution

4. The Strategy Meeting, Pitch + PRD

5. Analyzing 10 the top MCP Servers

6. Building It - Claude Code Sprint

7. Where Teams Go Wrong

Sections 1 and 2 are free. Sections 3-7 are for paid subscribers.

---

1. The 5 Distribution Channels - and Why #5 Changes Everything

Every generation of software has a dominant distribution channel. Every time the channel shifts, the companies that build for the new interface first win the decade.

Channel 1: Retail (1980s-90s)

Software came in boxes. You drove to CompUSA. Distribution meant shelf space. Microsoft won by getting Windows pre-installed on PCs.

Channel 2: Web (2000s)

Google changed everything. Distribution shifted to search rankings, landing pages, and self-serve signups. Salesforce killed on-premise with a URL. I wrote about how this shaped activation and onboarding as core growth levers, and why PLG became the dominant go-to-market.

Channel 3: Mobile (2010s)

The App Store created a new discovery surface. Companies that designed for small screens from day one (Instagram, Uber, WhatsApp) ate companies that tried to port desktop. I covered how growth loops compound differently on mobile.

Channel 4: AI Discovery (2020s)

LLMs started answering questions instead of linking to websites. If ChatGPT describes your competitor instead of you, you lose the click entirely. I wrote about this shift in my AEO/GEO guide, the new discipline of making your product visible to AI answer engines.

Channel 5: Agent Distribution (Now)

This is the one Karpathy is talking about. Agents don’t discover products through search results or app stores. They discover them through CLIs, MCP servers, and machine-readable documentation. They don’t onboard. They don’t browse. They connect, authenticate, execute, and move on.

Each channel shift followed the same pattern: the companies that built for the new interface first captured outsized market share. The ones that tried to retrofit lost ground they never recovered.

This shift appears to be happening faster than most interface transitions. Major platforms, model providers, and infrastructure vendors are aligning unusually quickly.

The Numbers

MCP, the Model Context Protocol, went from zero to 97 million monthly SDK downloads across Python and TypeScript in its first year.

10,000+ active MCP servers. OpenAI, Google DeepMind, Microsoft, and Cloudflare all adopted it. In December 2025, Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation because the standard had already emerged as the early leader. OpenAI and Block joined as co-founders. Google, Microsoft, AWS, Cloudflare, and Bloomberg as supporting members.

Gartner projects that 40% of enterprise applications will embed task-specific AI agents by end of 2026, up from less than 5% in 2025. That’s one of the steepest adoption curves in enterprise history.

So the channel is real. The adoption is real. The question for PMs is: what do you actually build?

---

2. The Agent-Accessible Product Stack - What to Build First

Your API is always the foundation. MCP servers call it under the hood. CLIs call it under the hood. If your API is a mess, everything above it will be too. If your auth is broken, neither MCP nor a CLI will fix it.

On top of your API, you build three surfaces. Most companies end up with all three. They layer, they don’t replace each other, and the order you build them matters.

Layer 1: Documentation

AGENTS.md is the emerging standard for telling agents how to work with your codebase and product. It emerged from collaborative efforts across OpenAI Codex, Google’s Jules, Cursor, GitHub Copilot, and Amp.

Think of it as a README, but written for machines instead of humans. OpenAI donated it to the Agentic AI Foundation alongside MCP.

GitHub analyzed 2,500+ AGENTS.md files and found a clear split between ones that work and ones that don’t. The effective ones put executable commands early, show code instead of prose, set clear boundaries on what agents should never do, and specify exact framework versions. 60,000+ projects have already adopted the format. OpenAI’s own repo has 88 AGENTS.md files, one per package.

The companion to AGENTS.md is an OpenAPI spec. If your API docs are scattered across Notion pages and README files, agents can’t parse them. An OpenAPI 3.0 spec is a machine-readable contract: every endpoint, every parameter type, every error code in one structured file. Tools like Speakeasy and Gravitee can auto-convert an OpenAPI spec into an MCP server. No spec, no conversion.

Vercel is pushing this further with Agent Skills: packaged instruction folders (SKILL.md files) that give agents specialized expertise. Stripe, Cloudflare, Supabase, Sentry, Expo, and Hugging Face all publish official agent skills. They work across Claude Code, GitHub Copilot, Cursor, Gemini CLI, and others. It’s another documentation surface that’s quietly becoming a distribution channel.

That’s where every team should start.

Layer 2: CLI

Karpathy’s point about CLIs being “legacy” technology is precise. Legacy means battle-tested, standardized, universally parseable.

The entire Unix philosophy was accidentally designed for AI agents decades before they existed: small composable commands, JSON output piped between tools, environment variable auth, structured exit codes.

A quick clarification on how CLIs relate to APIs, since this trips up a lot of PMs:

• Your API is the engine. It’s the raw programmatic interface.

• A CLI is a structured wrapper around your API that makes it composable: piping output to grep, chaining commands with jq, using environment variable auth.

• An MCP server is another wrapper, this one designed specifically for AI clients to discover and call tools through a standard protocol.

They’re layers, not alternatives, and each adds a new surface for different types of consumers.

Stripe’s CLI lets you pipe JSON responses to jq, chain subscription queries with customer lookups, export data in CSV. That existed years before MCP.

Now agents use it natively. Same story with AWS CLI, Terraform, Docker, GitHub’s gh, and Vercel’s CLI.

These companies built CLIs for developer productivity and got agent-accessible infrastructure for free.

Layer 3: MCP Server

This is where the biggest investment happens, but it’s also where the quality gap between companies is widest. An MCP server exposes your product’s capabilities as tools that Claude, ChatGPT, Cursor, Copilot, and thousands of other clients understand through a single standard protocol.

For many developer and B2B tools, an MCP server is quickly becoming table stakes. Having a good one is the competitive advantage.

What Makes a Good MCP Server

The difference between good and bad comes down to a few things most teams get wrong:

1. Tool descriptions. This is where most MCP servers fail. If your tool says “manages tasks,” an agent doesn’t know whether it creates, reads, updates, or deletes. Research on MCP tool selection shows agents start failing at 30+ tools when descriptions overlap, and virtually guarantee wrong picks at 100+. The Speakeasy team found that reducing Playwright’s MCP server from 26 tools to 8 dramatically improved agent accuracy. Design tools around outcomes, not endpoints. One track_order(email) that calls three APIs internally beats three separate tools the agent has to chain.

2. Auth without a browser. OAuth 2.0 device flows work: show a URL and code in the terminal, user approves in browser, agent gets the token. API keys for server-to-server. No browser-dependent auth in the critical path.

3. Structured errors. “API_TOKEN is invalid, reconfigure the MCP server” is actionable. “Access denied” is not.

4. Idempotent endpoints. Agents retry. They will call the same endpoint multiple times on a timeout. Handle duplicates gracefully.

5. Clear rate limits. Return 429 status codes with Retry-After headers. Agents that hit opaque limits will either crash or hammer you exponentially.

You want to push your team to get to this level.

---

Everything below is for paid subscribers.

The free section tells you what this channel is. The paid section gives you the part most teams will actually need help with:

• The 5-question audit to score agent readiness

• The stakeholder pitch to win leadership buy-in

• The PRD template for your first agent-access initiative

• The Claude Code sprint from zero to working implementation

• 10 production teardowns to copy the right patterns

• The 7 mistakes that make agents ignore your product

Most posts on this topic explain MCP. This section shows you how to actually get the initiative approved and shipped.