There’s a case study that gets cited often in the MCP builder community: a tool hit ten thousand dollars in monthly recurring revenue in six weeks, with zero marketing budget and zero outbound effort. The only channel was the marketplace it was listed in.

The lesson people take from this is usually about the product — it must have been really good. But that’s not the interesting part. Lots of tools are really good and don’t find users. The interesting part is that the distribution channel worked.

Protocol-native marketplaces create a new category of distribution that didn’t exist before. When the tool lives inside the same environment the user already has open, discovery and installation are close to zero-friction. The user doesn’t go looking for software; they encounter it in the context of doing work. That’s a fundamentally different acquisition dynamic than anything that requires users to visit a website, sign up for a trial, and decide to adopt a new workflow.

This doesn’t mean distribution does the work of product. A bad tool still fails. But it means that in protocol-native markets, your distribution strategy is a product decision, not a marketing decision. Choosing the right marketplace, structuring your pricing to fit that marketplace’s buyer behavior, and designing your free tier to convert the way that marketplace’s users evaluate tools — those are as important as what the tool actually does.

The builders who understand this early build the distribution relationship in from the start. They don’t ship a finished product and then figure out how to sell it. They understand the marketplace they’re building for before they write the first line of code, because the marketplace constraints shape what you build.

Distribution isn’t a secondary concern. In a protocol-native market, it’s half the product. +++