Even though all decent engineers have their preferences, none would dismiss one technology entirely in favor of another, and the sheer profusion of options available is a testament to that. Each new innovation brings something to the table, and no technology dominates all others in every aspect. After all, GraphQL didn’t kill REST, Cassandra and MongoDB haven’t replaced Postgres, some still prefer Emacs over vi (that one’s debatable, but let’s stay focused 😈), and we still use very similar languages like Python and Ruby that are, most of the time, interchangeable.

Somehow, AI broke that unwritten rule. Now a technology can be crowned king on Monday and publicly executed by Friday.

From King to Pariah

MCP has a very interesting story. After a few months of intense fame, with companies rushing to slap MCP onto every roadmap, many thought it was time to chop its head off the moment the next trend appeared (after all, beheading royalty is some sort of a French tradition).

As it turns out, MCP isn’t quite ready for the guillotine. The protocol is still strong with plenty of ammunition left and a lot to offer the ecosystem. And in fact, most of the criticism directed at MCP comes from treating it as something it was never meant to be.

To understand why, we first need to go back to what MCP was designed to do in the first place.

Why Did We Need MCP?

MCP stands for Model Context Protocol. It’s basically a specification initiated by Anthropic in November 2024 to provide a standardized and secure way for LLMs to interact with applications, and external services overall.

At the time, this was revolutionary. LLMs were isolated, mildly intelligent tools, able to spit out text but unable to interact with the outside world, and MCP was the most elegant way to make them more capable.

It wasn’t perfect. Like every new technology, it took time to mature. After months of iteration, community contributions, and convincing developers that the approach was worth adopting, the real inflection point came when Cursor embraced it. That gave MCP the visibility it needed to become a de facto standard, and adoption quickly spread across the industry. In that sense, MCP was unusually fortunate. By comparison, it took decades for JavaScript to achieve (almost) consistent support across web browsers.

From that moment on, MCP became the superstar. And with stardom came excess. As with any popular technology, people started reaching for it everywhere. But you don’t need MCP for everything, just as you don’t need Kubernetes to run a personal blog or a blockchain to store your shopping list.

Even worse, as an early protocol in a still-fragile ecosystem that was actively figuring itself out, MCP attracted criticism for things that were either unfinished or never intended use cases in the first place. More often than not, it was the latter.

And Then Skills Made Things Blurry

Interestingly enough, the real coup de grâce came from MCP’s own creator: Anthropic. They introduced something as simple as a Markdown file, cleverly branded as a Skill. In practice, it’s just a set of instructions written in plain English that can describe anything from trivial coding style preferences to something as complex as how to use an API or interact with an external service.

That’s pretty awesome: in theory, anyone can populate their repository with a bunch of MD files to fit their needs without any technical expertise, usually written by the agents themselves (”you’re absolutely right, this should never happen again, let me add this to CLAUDE.md“), which is just a recipe for lazy implementation, messy organization, a lack of prioritization at best, and disaster at worst.

I’m not saying, by any means, that Skills are inherently bad. They’re extremely useful. But like any technology or philosophy, they require discipline and have a well-defined scope where they excel:

  • Listing a sequence of steps or an order of operations

  • Defining a tone, style, or set of rules

  • Suggesting templates for outputs

  • Enforcing good practices

  • And so on

That said, Skills are neither omnipotent nor perfect. They rely on LLMs and their probabilistic behavior rather than deterministic, hard-coded logic. As a result, rules will occasionally be ignored, misunderstood, or misapplied, leading to anything from minor mistakes to catastrophic failures.

Still, everyone should be using Skills to make their work more efficient and their prompts less verbose. Instructions such as “please write and run tests on a regular basis”, “stop writing useless fallbacks and remove legacy code whenever possible”, “under no circumstances should you delete the production database” are great examples of the kind of guidance that belongs in a Skill.

So Why MCP Is Still Highly Relevant

On the other hand, MCP is a standardized protocol, not a freestyle playground and not merely an interface. You can’t simply improvise it. It requires a certain level of engineering discipline, but that comes with significant benefits.

If you need secure authentication, governance, transaction handling, or workflows that require deterministic behavior, MCP is the right tool for the job, even if that comes at a token cost (yes, MCPs are still painfully token-hungry). Would you trust a bank to run on a collection of Markdown files?

A Skill might work most of the time, but MCP provides actual safeguards. And when things go south, as they inevitably will because MCP still relies on AI under the hood, you can lean on the things developers have spent decades building: observability, governance, auditing, retries, fallbacks, and operational controls. That’s far preferable to reading an LLM’s heartfelt explanation for why it accidentally deleted your website.

Like any well-designed architecture, MCP also acts as a single source of truth. It can be centrally hosted, versioned, and maintained instead of being scattered across repositories as Markdown files, hidden in personal ~/dotfiles directories, or duplicated with slight variations by every developer on the team. There is, for example, no universally accepted way to distribute and update Skills (tho, that may not stay true for long).

You may argue that this introduces complexity, and you’d be right. But complexity is often the price of reliability. When something breaks, you know where to look, how to reproduce the issue, what to improve, and how to fix it for every user rather than patching individual workarounds.

From Daily Dose of Data Science

Discovery is another major advantage. Markdown files are inherently fragmented and difficult to navigate at scale. MCPs can expose structured capabilities, explicit documentation, and well-defined processes, resulting in a far more predictable and discoverable experience for both developers and agents.

MCP UI: How Build Smooth Agent Embedding

There’s another reason MCP isn’t going anywhere. It helps bridge the gap between the web as we know it (in the web browser) and modern AI assistants. As MCP and its surrounding ecosystem mature, major AI applications such as ChatGPT, Claude, and Gemini are increasingly adopting rich interactive components (following MCP UI guidelines) instead of relying solely on text and occasionally images. Forms, tables, selectors, charts, and other UI elements can now be surfaced directly within the conversational experience.

It’s still early, so most users haven’t fully experienced this shift yet. But this is the next logical step in the evolution of AI assistants.

For many use cases, graphical interfaces remain unmatched in terms of speed, clarity, and usability. Ordering a pizza, booking a flight, comparing hotel options, reviewing a table of results, or filling out a form are all tasks where a GUI is simply more efficient than a back-and-forth conversation.

That said, having a standard, especially one this young, doesn’t mean the path is straightforward.

When you submit an application for review, you’re not merely submitting code as you would when deploying a website. AI assistant providers such as ChatGPT evaluate the entire experience, and reviewers tend to be remarkably strict. They care about the quality of the interaction as much as the underlying implementation.

A clever app with sloppy test cases, vague tool descriptions, misleading UX, dark patterns, or a privacy policy that doesn’t accurately reflect what the tools actually do will likely be rejected. Much like the iOS App Store, these ecosystems care deeply about trust, safety, consistency, and user experience.

When Skills/CLIs Are Better

When people compare MCPs and Skills, they often frame the discussion as an MCP call versus having a Skill invoke a CLI command directly. This means the real debate is not MCP vs Skills but more MCP vs CLI, since plenty of Skills call MCP servers under the hood anyway. The real question is whether a given task wants a structured protocol call or a quick CLI invocation.

And to be fair, the command line has some obvious advantages. It’s familiar to virtually every developer and has proven itself over decades of use.

It’s also highly token-efficient, which remains one of the most common criticisms of MCP. In today’s environment, where providers such as Anthropic are paying close attention to inference costs, that’s a legitimate concern. At least for now: techniques like “code mode” and “tool search” let the agent load only the servers and tools it actually needs, avoiding bloating the context window. But overall, you could claim the CLI usage is more straightforward, with lower overhead and simpler execution.

So let’s put an end to the pointless debate about which technology is best. Skills can be extremely powerful, easy to iterate on, easy to debug, and a great place to encode local preferences. But they can only provide a fraction of what the MCP can offer.

MCPs address an entirely different class of challenges: standardized integrations, governance, authentication, discoverability, observability, rich user interfaces embedded in AI applications, and shared infrastructure.

Skills and MCPs are not competing technologies. They’re complementary tools, each optimized for a different set of tradeoffs.

How to Design A Good Managed MCP Server?

You could do it the hard way. MCP is, after all, a well-documented standard. But building and operating a production-grade MCP infrastructure leaves very little room for improvisation if you want to deliver on its promises.

The first one is purely infrastructure management. You could reinvent the wheel, of course (here’s my take), and can spend days implementing OAuth flows, token refresh mechanisms, access control, secret management, configuration management, observability, live debugging, secure log storage, and defending against the endless stream of supply chain attacks that now seem to arrive daily.

The alternative is to rely on platforms that handle this complexity and maintenance for you.

For the same reason you wouldn’t build your own web framework just to serve a website, platforms such as Bump.sh (disclosure, I am an investor) take care of the heavy lifting. Authentication, governance, infrastructure concerns, operational tooling, and protocol evolution become someone else’s problem. More importantly, they continue to be someone else’s problem as the ecosystem evolves, because the specifications will change. They always do.

That’s precisely why companies such as Redpanda, Elasticsearch, Memo Bank, MongoDB, and Lightspeed (which all have loads of talented engineers) choose to work with Bump.sh.

The second challenge for building an efficient MCP server is design, or more specifically AX (aka Agent Experience).

Sebastien Charrier, founder of Bump.sh, has spent part of his career operating systems that handled billions of API calls at Trainline, Europe’s leading rail travel platform. He has seen all the API tools taking the easy path: translating APIs to MCPs and claiming to be AI-ready, but he never thought that was the right way to do it.

Reducing MCP to a thin API wrapper is one of the biggest mistakes and MCP should be thought - as any user interface - as a comprehensive system for delivering a service. Most likely a series of scenarios that can go from A to B deterministically while still leveraging the abilities of LLMs (generate an invoice, deploy a version, analyze a ticket, you name it), with all the methods, observability, and error messages needed to understand what went wrong.

The goal is not to expose an API. The goal is to deliver a service.

How to Build The Best ChatGPT App?

The same rules apply when you want to embed your service within ChatGPT. Building a ChatGPT app is not rocket science at first glance. After all, we’re engineers. But the real difficulty lies in understanding why you keep getting rejected by one AI assistant provider or another, even though all the technical requirements are met (you definitely should read this).

More importantly, even though I believe every service should be present on these platforms, provide the best possible embedded UX, and start learning now before it’s too late (there’s a good chance they will become the future of the web, or at least capture a significant share of the market), that doesn’t mean they should spend their time crafting the engineering side of it.

Just like with managed MCP platforms, you should leave this work to specialists and focus on what matters most instead of struggling with the early quirks and rapid evolution of MCP, and MCP UI requirements.

Alpic is probably the best option on the market. That’s not a “trust me bro“ claim. I’m an investor, so weigh that, but it’s also considered as the first option by OpenAI itself.

There are two ways to use Alpic: you can let them handle the heavy lifting for you as a fully managed platform, or, if you’re more of a control freak and want to learn along the way, you can build on top of their open source library, Skybridge (1.6k GitHub ⭐ and counting), and benefit from a polished foundation while retaining full control.

MCP or Skills? Yes

So where does that leave us?

As Sohrab Hosseini, CEO of Orq.ai puts it, “MCP is about access to external systems, tools, and data, while Skills are reusable behaviors, workflows, and prompts.” For developers, combining Orq’s MCP capabilities with Skills works remarkably well.

And the line is already blurring in the right direction, Pierre-Louis Theron, CEO of Alpic, told me. An upcoming MCP release will likely include serving Skills over MCP, giving Skills a trustable, centrally-sourced distribution channel and letting agents pull them in alongside other services, or even chain them together. The two aren’t converging by accident: they were always meant to fit together.

AI evolves at a pace that often leads people to assume that every new technology is destined to replace the previous one. In reality, most innovations add a new layer of abstraction, control, or capability rather than making existing tools obsolete.

The industry also has a tendency toward extreme positions and bold claims, which is part of what makes it so fascinating, entertaining, but also occasionally a little alienating.

The same applies to MCP. Please do not throw the baby out with the bathwater.

The next time you’re unhappy with a company’s MCP, don’t blame the protocol. Blame the fucking implementation.