Why most MCP servers won’t last and that’s okay

MCP servers are everywhere right now. If you browse the /r/mcp subreddit, you’ll see dozens of new servers pop up daily, usually vibe-coded, often short-lived.

This post is a reflection on what MCP servers are, why they’re so popular, and why I believe most of them are destined to become unnecessary.

What Is an MCP Server?

Large Language Models (LLMs) are inherently limited: out of the box, they can’t read files, browse the web, or execute commands. They only know what they were trained on.

To overcome these limitations, developers introduced tools. With tools, LLMs can include specially formatted snippets in their responses that trigger external actions. For example:

“If you need to read a file, use read_file followed by the filename.”

MCP servers are one way to provide these tools. They allow LLM-based applications to extend their capabilities by acting as standardized tool interfaces.

Why Are MCP Servers Everywhere?

There are three main reasons:

  1. They’re Trending
    Much like NFTs in 2014, MCP servers are having a moment. Everyone wants to build their own.

  2. They’re Easy to Build
    If you can read from standard input and write to standard output, you can build an MCP server, in any language.

  3. They Offer Instant Gratification
    Most of the work is handled by the LLM, but it feels magical to interact with a system in plain language. Instead of typing --fancy at the command line, you can say “make it look nice”, and the agent will figure it out for you.

What Are MCP Servers Actually Used For?

In practice, most MCP servers serve one of two purposes:

1. Context Offloading

LLMs have a limited memory window (context). MCP servers help offload information the LLM can retrieve later.

For example, the popular sequential-thinking server allows the LLM to store and retrieve short notes. Other servers support vector databases, fuzzy search, and code indexing, all of which help the LLM remember or retrieve information it would otherwise forget.

2. Token Optimization

Some MCP tools are simply shortcuts: instead of having the LLM figure out how to do something, you give it a purpose-built tool. This saves tokens and speeds up responses.

The Overlap with Built-In Capabilities

Here’s the catch: many of the things MCP servers do can already be done without MCP servers.

LLMs trained to use tools often know how to:

  • Read and write files
  • Use curl, grep, sed, etc.
  • Execute Unix or PowerShell commands
  • Run Python or JavaScript scripts

If they don’t know how, they can learn, or be prompted.

So, technically, most MCP servers could be replaced with a combination of prompts and standard tools. It might be a bit slower, but it works.

MCP Servers as API Middleware

There’s a third category of MCP servers: those that act as middleware for existing APIs.

At first glance, this seems unnecessary. LLMs can already read API documentation, generate a JSON request, and send it using curl.

But in reality, many APIs are:

  • Poorly documented
  • Inconsistently designed
  • Burdened with legacy structures and naming

LLMs struggle with these things. They like clean, predictable, well-structured data. They don’t do well with vague, verbose documentation that omits key details.

In this context, MCP servers act as simplified, more LLM-friendly interfaces over complex APIs, kind of like refactoring the API without breaking it for existing users.

Why Most MCP Servers Are Redundant

Many current MCP servers are autogenerated from OpenAPI specs, and inherit all of the original API’s flaws.

This often results in an interface that looks new but behaves the same. In practice, it doesn’t help the LLM very much.

If the API is already clean and well-documented, an MCP wrapper adds little or no value. A well-prepared LLM can already use it directly.

Even better: the improvements that help LLMs: simple, concise, example-driven docs, also help human users.

The Future: Smarter APIs, Fewer MCP Servers

Over time, we’re likely to see tools that:

  • Clean up existing APIs automatically
  • Convert messy docs into structured, consistent formats
  • Present data in ways LLMs (and tools that use them) can easily parse

When that happens, the need for MCP servers as API wrappers will disappear.

Design for the Future, Not the Fad

If you’re building a new API today, test it like this:

Give an LLM access to the documentation and ask it to use the API.

If it struggles, don’t build an MCP server; fix the documentation. If the LLM can figure it out, so can your users.

Are MCP Servers Still Worth Building?

Sometimes, yes.

Some MCP servers offer useful side-effects, like acting as secure proxies to avoid leaking secrets to LLM providers. But even then, these are generic features. They could be built once and reused, rather than implemented in every MCP server from scratch.

More broadly: we’re still early in this space. LLM adoption is new. MCP servers are newer. The ecosystem is still evolving.

These tools might not be the destination, but they are a useful step along the way.

Final Thoughts

That’s why I think most of today’s MCP servers will eventually become obsolete. Their functionality will be folded into better APIs, smarter agents, and more capable LLM tooling.

In the meantime, we’ll keep experimenting. And that’s okay.

Every fad leaves behind a few things worth keeping.