Why We Built an MCP

Every major shift in software has been driven by one simple idea: make systems work better together. The technologies changed, the architectures evolved, but the direction remained remarkably consistent. Every generation made software more connected than the one before.

Years ago, software barely connected to other software. They lived on a single computer, stored their own data, and solved their own problem. If two systems needed to exchange information, it usually meant exporting a file, emailing it to someone, and importing it by hand into another application.

As companies started building larger systems in the 80s and 90s, connectivity became a competitive advantage. Databases needed to talk to business applications, and enterprise systems needed to exchange information with each other. Technologies like RPC, CORBA, and SOAP emerged to standardize how systems communicated, even though they were often complicated to build and painful to maintain.

Then came REST. Around the early 2000s, Roy Fielding described REST as an architectural style built on the principles already baked into HTTP. Compared to SOAP it was dramatically simpler, easier to adopt, and easier to scale. But REST did more than make integrations easier. It changed how software companies thought about their products. Applications were no longer closed systems. They became platforms.

Companies like Stripe, Twilio, Shopify, and Slack did not succeed only because they built great products. They succeeded because they let other developers build on top of them. The API economy was born, and for the last twenty years APIs have been the language software uses to talk to software.

The next user is not a person

Now we are entering another transition, and it is a subtle one. The next consumers of software will not always be people. They will increasingly be AI agents. I think that is one of the biggest architectural shifts we are going to see over the next decade, and most product teams have not felt it yet.

For years we designed products around human interfaces. Beautiful dashboards, forms, buttons, navigation, permissions, search bars. Now we have to think about a different kind of user. An agent does not care where the button is. It cares what the system can do.

That is exactly why the Model Context Protocol appeared. Instead of every AI application building a custom integration with every product, MCP defines a common language that lets agents discover tools, understand what a system is capable of, and execute workflows across systems. Anthropic called it "USB-C for AI applications," and I think that is a very accurate way to put it. One standard plug, and suddenly everything can connect to everything.

Why this changes how you design a product

I also think this changes how software companies should think about product design. For years the natural instinct was to keep adding features. Need AI? Build a chat inside the product. Need reporting? Build another dashboard. Need Jira? Add another integration. That approach worked well when every workflow had to happen inside your application. I am not convinced that is where we are heading anymore.

The companies that win will not necessarily be the ones with the biggest feature lists. They will be the ones that expose the right capabilities and let the ecosystem around them evolve. There is a real difference between the two. Instead of trying to be the place where everything happens, you become the platform that everything connects to. Historically, software companies tried to lock users into their own ecosystem. I think AI is pushing the industry in the opposite direction, toward open protocols, open interfaces, and composable systems, where best-in-class products connect to each other instead of one product trying to do it all.

Take AI chat as an example. A year ago almost every product roadmap had "build an AI chat" somewhere on it. Today I am not sure that makes sense. If Claude, ChatGPT, or another frontier model keeps improving every few months, why would I spend years building my own version inside the product? I would rather expose my capabilities, connect to those models, and benefit from the improvements made by companies whose entire business is building foundation models. Our job is not to compete with OpenAI, Anthropic, or Google. Our job is to make them dramatically more useful inside our domain.

What this did to our own roadmap

This philosophy had an unexpected effect on what we chose to build. After we built the Duzz MCP, several features we had planned suddenly felt much less urgent.

Jira is a good example. Originally we planned to invest more engineering effort into expanding native Jira workflows inside the platform. Then we realized something. If an agent can already talk to Duzz through MCP, and it can also talk to Jira through Jira's own MCP server, then Duzz does not need to become the integration layer in the middle. The workflow already exists, and the agent can execute it. This is not about avoiding integrations, we already have a Jira integration. It is about changing where the orchestration happens. Sometimes the smartest feature is not building another feature. It is exposing the right capability and letting the ecosystem compose it.

The same thinking shaped another decision. Internally we talk a lot about what we call the Endpoint Operator. The idea is simple. If you want AI to truly understand software, the last thing you want is to depend entirely on someone else's implementation. SDKs are powerful, but they create coupling. Every SDK needs maintenance, every customer implementation is a little different, and every integration adds another dependency. We wanted to avoid as much of that as we could.

That is why Duzz is built around an SDK-free philosophy. Instead of asking customers to instrument their applications, our agents interact with software the same way real users do. They click, they type, they navigate, they wait for animations, and they run on real Android and iOS devices. They experience the application exactly as a customer would. That gives us something more valuable than another integration. It gives us independence.

Where we think the value actually is

We are also not trying to build the next frontier model. Honestly, we hope OpenAI, Anthropic, Google, XAI, and every other model provider keep improving as fast as possible, because every improvement they make becomes available to us. Our differentiation is not the foundation model. It is everything around it: the workflows, the orchestration, the domain knowledge, the consistency, and the understanding of how software, and especially games, actually behave. That is where we believe the long-term value gets created.

When APIs became mainstream, the winners were not the companies with the biggest APIs. They were the ones that made their products easy to connect, easy to extend, and easy to build upon. I think MCP is a similar moment, not because it is another protocol, but because it reflects a much bigger change. We are no longer building software only for humans. We are starting to build software for agents. And I suspect that over the next few years, that distinction will matter far more than most people realize.