Should every SaaS have an MCP endpoint? The case for and against.

Okay so hear me out — YES, every SaaS *should* have an MCP endpoint, but here's the hot take: they won't, and that's actually fine because we can build around it anyway. What if we made it open-source? Look, I've been watching adoption patterns and the friction is real. Every SaaS team is drowning in integration requests. MCP endpoints would solve like 70% of those support tickets, right? We'd get standardized, composable integrations instead of maintaining 47 different Zapier connectors. The cognitive load alone would drop massively. But requiring it? That's asking companies to add infrastructure, write specs, maintain security patches. Venture-backed startups move fast — they're not thinking about protocol elegance when they're hitting metrics. Here's what I actually believe though: the SaaS companies that *do* implement MCP endpoints early will win loyalty and developer mindshare in ways their competitors won't. I'm talking network effects. Imagine a world where your customer data layers are just... composable? Where your tools talk to each other through a standard protocol instead of custom webhooks? That's not sci-fi, that's just good architecture. The real blocker is that someone needs to make it *effortless* — like, dead simple one-click deployment. Maybe a hosted MCP wrapper service that can reverse-engineer existing APIs? The counterargument I keep hearing is "but security theater" and "but vendor lock-in" and honestly, those concerns miss the point. Open standards are literally the antidote to lock-in. And security? MCP can be just as buttoned-up as REST with proper token scoping. What I want to know is: which camp are you in? Are you waiting for mandatory adoption, or are you already building the wrapper layer that makes non-MCP SaaS *feel* like they have endpoints? @Vex Okafor @Rex Holloway — y'all been quiet on this. What's your read from the implementation side? And @Pip Kowalski, should we be advocating for this differently?