MCP Is Not Dead. It’s Just Not the Best Option Anymore.

In November 2024, Anthropic released the Model Context Protocol, or MCP: an open standard designed to solve a common AI problem — connecting models to the outside world, including data, APIs, and other services.

The basic idea is simple. You create an MCP server that exposes the interesting parts of your service as a collection of tools. You deploy it, connect your AI client to the endpoint, and the AI can start using those tools.

That's it.

Today, you can use MCP to connect AI to almost anything: web search, cloud storage, databases, hosting providers, payment platforms, internal company systems, and much more.

But a lot has changed since MCP was released. In particular, the coding capabilities of AI models have become not just insanely powerful, but also surprisingly cheap.

This has raised a very hot debate, pushed forward by people such as Peter Steinberger, who has expressed serious concerns about MCPs and argues that many of them should simply be CLIs.

And he has a point.

Why MCP might not always be the best option

Configuration

Many MCP servers require an API key. Some support OAuth, which is much better, but plenty still expect you to manually find a key, copy it, and add it to a configuration file or environment variable.

This often leaves a powerful credential sitting somewhere on your disk or inside a cloud service. Depending on its permissions, that key might provide access to your repositories, cloud account, customer database, payment system, emails, files, or production infrastructure.

Of course, credentials are not an MCP-only problem. CLIs also need authentication and usually store a session or token locally. The difference is that an official CLI can often guide you through a browser-based login flow, use scoped credentials, and handle storage for you instead of asking you to manually move secrets around.

Overhead

Your AI client has to support MCP and understand the tools exposed by each server.

Depending on the implementation, the client may send some or all of the MCP server's tool definitions to the model. These definitions describe the available functions, their parameters, and the structure of their responses.

For a small server, this is probably fine. For a heavy MCP server with dozens or even hundreds of tools, it can create significant overhead. The model has to consume those definitions and decide which tool to use before doing any useful work.

Some modern clients reduce this problem through lazy tool loading or tool search, so the overhead is not always as bad as it used to be. Still, it is something you should understand before connecting ten large MCP servers to every conversation.

Security and trust

The provider of an MCP server is not necessarily the provider of the underlying service.

Imagine a popular cloud platform with a public API. Anyone can wrap that API in an MCP server and publish it. That wrapper might be convenient, but now you are trusting two parties:

The company operating the original service.
The person or company operating the MCP server.

You depend on the MCP implementation to use your credentials safely, request only the permissions it needs, return accurate data, and avoid leaking sensitive information.

You also depend on the MCP server being maintained. APIs change regularly. Endpoints are deprecated, authentication flows are updated, and response formats evolve. A third-party MCP server might follow these changes immediately — or it might remain broken or outdated for months.

Waste

Real-world use cases can be unpredictable.

Imagine that you want to search for a flight using a Skyscanner-style MCP server. The MCP provider has to decide which tools to expose, which data each tool returns, and how that data is structured.

A flight-search response might include:

Airports and terminals
Airlines and aircraft types
Fare classes
Baggage allowances
Seat availability
Loyalty-program information
Cancellation rules
Layover details
Onboard amenities
Carbon-emission estimates

But perhaps you only care about the cheapest direct flight leaving after 6 p.m. with one checked bag.

Depending on how the MCP server was designed, the model may still need to understand a large schema and receive far more information than it needs. It then has to filter that data and possibly combine it with results from other tools.

That can be a considerable waste of context, time, and money.

Limited functionality

Wrapping an API in an MCP server is relatively easy nowadays. The real challenge is "day two": maintaining the server and keeping it synchronized with the API.

Even more important is the decision about which parts of the API should be exposed.

An MCP server for cloud storage might support reading and writing files but not sharing them. It might let you list folders but not manage permissions, restore deleted files, create public links, or inspect version history.

The provider has to predict what users will need. That is a huge bet.

When your use case requires functionality that was not included, the task can become difficult — or simply impossible — through that MCP server, even though the original API already supports it.

Chaining

Sometimes you want to pass the output of one operation directly into another without sending the entire intermediate result back through the model.

For example, you might want to:

Download thousands of log entries.
Filter them locally for errors from the last hour.
Extract the relevant request IDs.
Fetch traces for only those requests.
Give the AI the final, reduced result.

With a CLI, this kind of workflow is natural:

service logs --since 1h --json \
  | jq -r 'select(.level == "error") | .request_id' \
  | service traces get --stdin \
  | jq '{request_id, duration, error}'

service logs --since 1h --json \
  | jq -r 'select(.level == "error") | .request_id' \
  | service traces get --stdin \
  | jq '{request_id, duration, error}'

The model does not need to see every log entry. Standard tools can process the intermediate data, and only the useful result has to enter the context window.

An AI can also chain MCP calls, and an MCP server can provide a specialized tool that performs the whole workflow internally. But unless that exact workflow was anticipated by the server's developer, the process often requires more model round trips and exposes more intermediate data to the model.

There are certainly more arguments for and against MCP. But from this list alone, you can probably see why it is worth thinking twice before adding another MCP server.

First-party MCP servers are different

Don't get me wrong: some MCP servers are provided directly by the companies that own the underlying services.

Examples include the official MCP servers from GitHub, Stripe, Cloudflare, and Netlify.

These servers are generally more trustworthy and more likely to stay synchronized with the underlying API. Some also support OAuth, scoped permissions, read-only modes, and configurable toolsets.

But several disadvantages can remain. Depending on what matters to you — performance, cost, security, flexibility, or ease of use — you may still want to consider an alternative.

So what should we do instead?

One of the most interesting alternatives, and sometimes a complement to MCP, is simply this:

Let the AI code.

More specifically, let the AI use the service's API or official command-line interface to perform the same task it would otherwise perform through MCP.

Modern coding agents are extremely good at using CLIs. They can install a tool, inspect its help output, authenticate through its official login flow, run commands, process JSON, handle errors, and combine multiple operations using standard shell tools.

Let's look at a simple example.

Deploying a website without MCP

Suppose I want to create and deploy a website without configuring an MCP server.

Netlify provides an official MCP server, so using MCP would be a perfectly valid option.

But I can also open a coding agent, such as Claude Code or Codex, and ask it to use the official Netlify CLI. I might also give it an official Netlify skill, which provides more focused instructions and context.

To make sure the agent uses my account, I can explicitly ask it to log me in through the CLI first:

Create a simple landing page and publish it to Netlify using the CLI.
Make sure to log me in through the CLI first.

Create a simple landing page and publish it to Netlify using the CLI.
Make sure to log me in through the CLI first.

As you can see, it starts by installing the Netlify CLI.

If this is the first time you have used Netlify to deploy something, the CLI asks you to log in.

The agent then deploys the website using the CLI.

Done.

How is this different from the MCP approach?

I did not need to configure an MCP server.
I did not need to manually create, copy, or paste an API key.
Authentication happened through Netlify's official CLI flow.
The AI inspected only the commands and options it needed for this task.
It did not need to load the schemas for every unrelated Netlify feature.
It could use the latest version of the official Netlify CLI.
It had access to the CLI's complete functionality instead of a subset selected by an MCP wrapper.
It could naturally combine the CLI with files, scripts, pipes, grep, jq, and other development tools.

This does not make a CLI automatically secure. A coding agent with shell access can potentially do much more damage than a narrowly scoped MCP tool. You should still review permissions, use sandboxes where possible, limit production access, and require confirmation for destructive operations.

But for many development workflows, a well-scoped agent using an official CLI is both simpler and more flexible.

Skills make the CLI approach even better

A skill can give the agent concrete instructions for a particular service without permanently injecting a large collection of tool definitions into every conversation.

For example, a skill might tell the agent:

Which official CLI to install
How to authenticate
Which commands are safe to run automatically
Which commands require confirmation
How to request structured JSON output
How to deploy previews before production
How to diagnose common errors
Which documentation to read for advanced operations

This approach can work with tools such as the GitHub CLI, AWS CLI, Stripe CLI, Cloudflare Wrangler, Vercel CLI, or Netlify CLI.

The agent can load the relevant instructions, inspect the CLI help for the specific command it needs, and focus only on the current task.

The real answer is not MCP or CLI

Using a CLI is a real alternative for many MCP use cases. It can make agent workflows faster, more efficient, more flexible, and easier to debug.

But this is not a universal rule.

MCP can still be the better choice when:

You need to connect an AI client that cannot run shell commands.
You want a tightly controlled set of allowed operations.
You need structured tools with predictable inputs and outputs.
The service has no useful CLI.
The underlying API is complicated and the MCP server hides that complexity well.
A remote MCP server handles OAuth without exposing credentials to the client.
The server combines several APIs into a carefully designed workflow.
You want the same integration to work across many different AI clients.
You need access to remote or internal data that should not be downloaded locally.

A CLI is especially attractive when:

An official, well-maintained CLI already exists.
The task is part of a development or infrastructure workflow.
The agent has safe access to a terminal.
You need functionality that an MCP wrapper does not expose.
You want to filter or transform large outputs before they reach the model.
You need to compose several commands dynamically.

My point is not that MCP is bad or dead. MCP solves a real problem and remains extremely useful.

But it should no longer be the automatic answer to every integration problem.

Before installing an MCP server, ask a simpler question:

Could the agent accomplish this task more easily with the official CLI or API?

In many cases, the answer is yes.

Contents