Every new technology has a moment when it feels more like a playground than a finished product. Right now, MCP, the Model Context Protocol, is in that moment. If you spend time in developer circles, you might hear a line repeated almost like a joke: “MCP is probably the only piece of tech that has more builders than users.”
At first glance, it sounds like criticism. What is the point of a technology if hardly anyone is using it? But the imbalance between builders and users is not necessarily a sign of failure. In fact, it is often how important tools grow. MCP is simply following the same path that many other foundational technologies have followed.
Why the Ratio Looks Odd
When we think about technology, it seems obvious that the number of users should be much larger than the number of builders. There are millions of people using apps like WhatsApp or Instagram compared to the small teams that created them. So when we see a tool where more people are experimenting with it than using it every day, it looks wrong.
Infrastructure works differently. The people who benefit from it are often not aware they are using it. APIs, containers, and microservices all began as playgrounds for engineers. At first, there were more experiments than working systems. Over time, some of those experiments revealed valuable use cases, the tools became easier to adopt, and only then did the rest of the world benefit.
MCP is in that middle stage. It is past the “just invented” phase, but not yet at the point where anyone can pick it up without deep technical knowledge. To outsiders, this stage looks like confusion. To builders, it is often the most exciting time.
The Show-Off Problem
One reason MCP is misunderstood is that it has become a kind of badge of honor for developers. Building an MCP connector is something people share publicly not because it solves a pressing problem but because it shows they understand modern systems. It has become a way to prove technical skill.
The trouble is that many of these projects never get used in production. They are clever demonstrations, similar to the early days of microservices when people built dozens of tiny services to serve a single web page. These projects are fun, they look good in a portfolio, but they do not improve anyone’s workflow.
This creates the impression that MCP is hollow. That it exists only for developers to tinker with. But this ignores the way infrastructure always grows. There is always a noisy first wave of experiments. The valuable patterns often hide quietly among the flashy ones. Over time, those patterns become the real foundation.
Where the Real Value Lies
The true benefit of MCP is not in showing off connectors that link five different systems. It is in writing a small MCP server to handle your own edge cases.
Every team has awkward workflows that do not fit neatly into ready-made tools. A database that does not sync cleanly. A support system that requires manual steps. A reporting process that breaks because data lives in three different places.
For years, the answers to these problems were either fragile custom scripts or heavy integration platforms that were too complex for what was needed. MCP offers a middle path. You can build your own lightweight server to smooth out those friction points without waiting for a vendor to release something perfect.
The irony is that many of the most valuable MCP use cases are invisible. They are not posted online. They are saving teams hours of manual work every week. They do not look impressive from the outside, but inside a company they can make the difference between frustration and smooth operation.
Innovation Before Adoption
This is why having more builders than users is not a failure. It is a sign of innovation happening before broad adoption. When builders outnumber users, people are free to try things that may not make sense yet. Every small project, even the ones that fail, pushes the limits of what the technology can do.
The real danger is not too many builders. The real danger is when nobody builds at all. That is when a technology truly dies. MCP is the opposite right now. There is so much energy around it that the number of builders will naturally outstrip the number of visible users. Adoption often looks small until suddenly it is everywhere.
Learning From History
We have seen this before. When APIs began spreading, there were countless projects that led nowhere. But APIs matured, became standardized, and now they quietly power almost every digital service.
The same happened with microservices. At first, companies divided their applications into dozens of tiny pieces just to say they had microservices. Most of those efforts failed. But the useful patterns survived, tools improved, and modular systems became normal practice.
Containers followed the same path. At first, people stuffed simple demos into Docker images. Today, containers are the foundation of cloud computing.
MCP is at the same stage. Many people are building for the sake of building, but out of that noise will come the workflows that truly matter. Once the complexity is wrapped into friendly tools, MCP will stop being something developers brag about and start being something everyone simply uses without noticing.
What Comes Next
So where does MCP go from here? Builders will keep experimenting. Some of those experiments will quietly solve real problems and those will spread. Toolmakers will notice and create easier ways for others to adopt it. At that point, the number of users will grow, even if those users are not aware they are touching MCP at all. It will become the invisible plumbing beneath other applications.
That invisibility is the real goal. Nobody brags about using TCP/IP anymore. Nobody thinks twice about APIs or containers. They are simply part of how modern computing works. MCP’s future is the same. The less people talk about it, the more it will have succeeded.
The Human Side
At the core is a simple question: are you building to show off, or are you building to solve?
The projects that last are always tied to human problems. They may not be glamorous, but they matter. Automating a painful manual task matters. Syncing data reliably matters. Making a workflow smoother matters.
The projects built only to impress will fade away. The projects built to reduce frustration and save time will continue to grow.
That is why the imbalance between builders and users is not worrying. It is temporary. It is the noise before the signal. Out of hundreds of experiments, a handful will stick. And those will create ripple effects far bigger than their modest beginnings suggest.
Final Thoughts
Yes, MCP looks odd today. More builders than users. More demos than production deployments. More technical flexing than practical solutions. But that imbalance is not a flaw. It is the way infrastructure has always grown.
The clever line that “MCP has more builders than users” sounds like criticism, but it misses the deeper truth. Infrastructure is not about user counts. It is about enabling other things. It is about laying the foundation for problems that do not yet have clean solutions.
The lesson is clear. If you are working with MCP, do not build just to impress. Build to solve. Focus on the edge cases in your own work. Make something your team would not want to live without. That is where the real value lies.
When you do that, the ratio between builders and users stops mattering. What matters is the problems you are solving and the time you are saving. Once enough people do that, MCP will no longer be a flex. It will be another quiet piece of the infrastructure that holds everything together.
MCP might be the only technology that has more builders than users. When there are more builders than users, new ideas often arise before people start using them. MCP: Why having more builders than users can be a good thing.