Coming off the Flow conference in Nashville last month, there was a great presentation from Rewst's CEO, Aharon Chernin that is worth re-sharing. We are re-posting a summary from Andrew Morgan that was posted on LinkedIn
I had Aharon Chernin, CEO of Rewst , on Monday's CyberCall. We spent most of the hour discussing Model Context Protocol (MCP) and there was a lot in there worth passing along. MCP is the open standard Anthropic introduced in November 2024 that lets AI models discover and interact with external tools, data sources, and systems through one shared, standardized interface, instead of needing a custom-built integration for every single model-and-tool combination.
This is the number that made me want to address this topic.
MCP isn't a fringe experiment anymore. Downloads of the open-source MCP SDKs, the toolkit developers use to build MCP servers and clients, went from roughly 100,000 the month the protocol launched in November 2024 to 97 million monthly by March 2026. That's a 970x increase in under a year and a half. By late July 2026, Anthropic, OpenAI, Google, Microsoft, and AWS jointly shipped the biggest spec update since launch, with a 12-month deprecation window for the old version.
We asked Aharon if MCP is a buzzword you can ignore? His answer was refreshingly honest: “it depends on you, not the tech.”
Aharon shared, MCP is "neither good nor bad," it's infrastructure, like TCP/IP or HTML. If you're an MSP doing nothing with AI yet, you can genuinely ignore MCP for now. If you're leaning into AI already, MCP becomes the thing that makes your AI actually useful instead of theoretical.
What MCP actually is, in plain terms.
Think of it as a standard way for an AI agent to discover and use a product's capabilities, without a developer having to hand write custom code for every tool combination. Before MCP, connecting 10 AI applications to 100 tools could mean building up to 1,000 separate point to point integrations. MCP collapses that into one shared connector.
Important nuance from the call: MCP doesn't replace REST APIs. REST is still what you want for moving large volumes of data. MCP is what you want when an agent needs to discover what it can do and act on it in a handful of steps, without a human writing integration code first.
The use cases that are working, not hypothetical.
A few concrete examples came up that are worth sharing:
Where MSPs are already getting it wrong.
Aharon didn't sugarcoat this part. Two mistakes keep showing up.
On the vendor side, some are trying to charge extra for MCP access to their own product. His take: that's backwards. If it adds value to your product, you want it used, not gated.
On the MSP side, the mistake is almost the opposite problem. MSPs who understand MCP conceptually often jump straight to the most complex use case first, instead of testing the basics, like; is the connection working, is the token scoped correctly, does a simple identity check even respond. Skip that, hit a configuration issue, and the conclusion becomes "MCP is broken" when the tool was never the problem.
His advice if you're starting from zero: don't touch MCP yet. Master using an LLM on its own first. Get comfortable with what it can and can't do without any tool access, before adding MCP into the mix. You can't appreciate what MCP adds if you don't know what's missing without it.
The vibe-coding trap.
This is the one I want every MSP owner reading this to consider. It's tempting to look at your subscription stack and think "I'll just build that myself." Aharon's pushback: replacing a product isn't a weekend project, even with AI accelerating development. His phrase for it, "80% done, 80% to go." The more you finish, the more you realize is left. And it's not a one-time cost. Once you've built it, you're now the one supporting it, maintaining it, and absorbing the token and headcount costs to keep it running. Do it for the wrong product, and you can end up paying more than the subscription you replaced.
There's a real question buried in here too. Does your cybersecurity insurance policy actually cover you if something you built breaks and causes a client problem? Nobody on the call had a confident answer, and that's the honest state of the industry right now. Cyber insurance hasn't caught up to MSPs writing their own software.
Security: the part that matters most for your clients.
Treat an MCP token like a user account, not a config setting. Ask whether you can scope it to least privilege, whether there's role-based access control, and don't assume broad access wasn't granted by default. Several people learned the hard way that a token had far more reach than they expected.
The bigger gap is observability. Most MCP servers today don't log who did what, when, in a way you could hand to an auditor or a SIEM. That's not something you can ask your AI agent to confirm for you either, since tool descriptions don't reliably include whether logging exists. You have to go check the product directly. If you're rolling out MCP for a client, this is where I'd start: don't assume logging exists just because the connection works.
The bottom line for your business.
MCP is standardization happening at a pace the tech industry rarely manages. Cybersecurity itself still isn't standardized after 25 years, and MCP got there in under two. That speed is exactly why it deserves your attention now, not in twelve months. But the lesson from today isn't "go implement MCP this week." It's this: get the fundamentals of AI right first, understand what you're actually connecting when you flip it on, and don't let the hype cycle pull your focus off the parts of your business that actually need it.