At this year's AI Engineer World's Fair, the most important protocol in the building was rarely the headline on the slide. The Model Context Protocol — MCP — showed up in talk after talk, sometimes named explicitly, more often just assumed as the substrate everything else stood on. You could sit through a session on context graphs, agent UIs, or coding harnesses and realize halfway through that the thing quietly making it work was an MCP server nobody bothered to introduce anymore. That's usually the sign a standard has won: it stops being the topic and becomes the plumbing.
What I want to trace is what I actually saw — team after team rewiring their products to live inside a chat interface — and the conclusion the conference kept pointing at without quite stating it: if you ship a SaaS product, a data product, or a set of API integrations, your MCP server is quietly becoming both your distribution and your moat.
Chat became the front door, and users always wanted it there
Start with the user, because the whole shift makes sense from there. People have always wanted everything in one place — it's the reason every "single pane of glass" pitch has sold for thirty years. What was missing was a way to actually deliver it. Getting two applications to share context meant a point-to-point API integration; getting ten to share meant ten of them, each with its own auth, its own data model, and real coordination across every application company. The combinatorics were brutal. And when companies did try to bridge their systems, the fix was rarely a quick connector — it meant standing up bespoke adapter and middleware layers whose scope and cost often rivaled the enterprise implementations they were meant to connect, a second project the size of the first. So the dream mostly stayed a dream, and the user did the integration in their head.
Three things changed at once, and MCP is the connective one. Context windows got large enough to hold real working state. Harnesses got good enough to plan, call tools, and recover from failure. And MCP gave every application a common way to expose itself to an agent instead of a bespoke one. Put those together and the thing users always wanted becomes buildable: a single agentic workload that pulls context from a couple of applications — or ten, or twenty MCP servers at once — and runs a workflow across all of them. The user stops being the integration layer. The harness is.
Chat is where this is landing, and I don't think it's a fad. It may not be the only interface we end up with, but it has staying power: more and more people treat a chat interface as their primary gateway into intelligence — the first place they go with a question, and the most convenient place to combine context from many applications into one request. When the front door moves, the products that want to be used move with it.
Team after team described the same rewiring
The clearest signal wasn't any single announcement — it was how many teams described the same journey: taking an existing product and rewiring it to show up inside chat through an MCP server.
- Figma told the most honest version. In "Building the engine while flying the plane", founding engineer Jesse Lumarie walked through building Figma's MCP server while the spec itself was still moving — prototypes, dead ends, architectural pivots, and eventually a fully remote server. What makes it demanding is that it isn't simple text-in, text-out: it passes real instructions against Figma design files, pushing on the edges of the protocol in ways a plain question-and-answer tool never does.
- The Gates Foundation showed the internal-knowledge version. In a talk titled "Your Moat Is Your Data Model," lead AI engineer Mike Phipps described surfacing the organization's context graph — the knowledge base of the whole institution — inside chat via MCP. Not a product to sell; a way to make the company's knowledge reachable by an agent.
- Indeed showed the frontier and its friction. Technical Fellow Dustin Mihalik's "MCP Apps: Give the Model Data, Give the User a UI" covered the opportunity in getting the MCP Apps extension into a host like Claude — interactive experiences instead of walls of text — while being candid that a new protocol still brings real technical challenges. The official extension (SEP-1865) got its own deep dive, a sign of how fast this is standardizing.
Different companies, different products, the same move. And it doesn't stop at product teams: one talk was pointedly titled "Who Approved That MCP Server?", because the moment servers become a distribution channel, an organization has to decide which ones it trusts.
Your MCP server is becoming your distribution and your moat
This is the part I keep coming back to. If you run a SaaS application, a data product, or a set of API integrations, MCP is getting hard to treat as optional. Your MCP server — and, more precisely, its adoption — is on its way to becoming both your distribution and your moat: the common surface that makes your product reachable wherever a user is working, inside the chat interface, alongside a dozen other tools, in the workload they're actually running.
We've watched a version of this happen before, twice. The web arrived, and the companies that shipped a real web application — not a brochure, an application — earned a decade of distribution over the ones that treated it as optional. Then mobile repeated it: the teams that built a genuine mobile app, tuned to how people actually held a phone, took ground from the ones that shipped a shrunken website and called it done. Each time, distribution followed whoever built for the new interface earliest and best.
MCP looks like that migration a third time. The interface is chat and the agent behind it, and the MCP server is how a product ships for it. Treating the server as a side integration rather than a product surface rhymes with treating mobile as a smaller website in 2010 — a reasonable-sounding call that aged badly. I don't hold that as a certainty, but it's the pattern the evidence keeps fitting.
This is an enterprise AI story, not only a SaaS one
It's easy to read this as advice for software vendors refactoring distribution. It's that — but the design of MCP servers is squarely an enterprise AI concern too, and it maps onto the three pillars we work across at AgentGraph:
- Enterprise AI — the internal business users. The Gates Foundation talk was exactly this: a server built for internal use, making an institution's own knowledge reachable inside chat.
- Product — MCP server build-outs. Figma's server is the archetype: a server as a core extension of an existing product, a new front door to something people already rely on.
- Agentic engineering — the CI/CD pipeline for teams shipping agentic systems. Many servers being built today exist to give coding agents better tools and context, reaching into documentation and internal systems so the agent knows what it's working with.
The same primitive shows up in all three. Surfacing internal knowledge, extending a product, feeding a coding agent: it's the same underlying move — exposing a system to an agent through a common, well-governed surface. And none of it was theoretical; for each pillar, a team had already built it and would tell you what broke.
What I'm watching next
Two developments have me optimistic about where this goes.
The first is MCP Apps maturing into a real UI layer. Most MCP tools still return text, and text is a floor, not a ceiling. As the extension gets adopted across hosts, a server can hand the user a rich, interactive experience inside the agent harness while handing the model clean, structured data underneath — the person and the agent each getting the representation that suits them. That's the difference between an integration that answers and one that feels like an application.
The second is skills over MCP. Today, how well someone uses your server depends on how good their model is at figuring out your tools and how well they happen to understand your product — a lot to leave to chance, especially for a first-time user. Skills over MCP would let a server ship audited, packaged workflows that encode the best way to use the exact tools it provides. Better still, a skill can be aware of the other servers a user already has connected — reaching for their CRM, say, and composing it with your tools to produce something neither delivers alone. Done well, skills become the backbone of an MCP-first product: the glue that lets a server cooperate with the rest of a user's workload instead of sitting in its own lane.
Neither is finished; both are being worked out in the open by the protocol's working groups. That's the part I find most encouraging — the interesting problems are being solved in public, which is usually how a standard earns its staying power.
The interface changed again
Web apps. Mobile apps. Now MCP servers. Each was a moment when the world chose a new way to interact, and distribution followed the teams that built for it early and well. Chat and the agent behind it are that interface now, and the MCP server is how a product ships for it. Nearly every company will face this over the next couple of years — the same decision their predecessors faced with the web and with mobile. Better to make it deliberately than by default.
AgentGraph designs agentic systems and places forward-deployed engineers with enterprise teams building exactly these surfaces — the MCP servers, skills, and harnesses that put a product or a knowledge base where users now work. If you're figuring out how to ship your product into the chat interface, let's talk.