Perplexity's CTO just said they are moving away from MCPs and will focus on APIs and CLIs instead.
In response, more companies have started taking a similar stance.
So after last year's boom… are MCPs becoming irrelevant?
Short answer: no.
Long answer:
What MCP was created for
The name MCP is quite explicit: it's a Model Context Protocol.
And that's exactly what they solve, providing information to our models that they previously lacked.
Examples:
- We want our agent to access our database to run queries.
- Or access our logging system.
- It's also useful for adding documentation about new library versions that our agents haven't been trained on.
- And for giving them browser control so they can see what they're coding.
Before MCPs, given the capabilities models had, we couldn't even imagine doing any of that.
When the protocol came out, we started treating agents in a whole new way.
So… what has changed since then?
What changed is simply that we've been using agents more and more and we've seen where they shine and where their limitations are.
Agent limitations
One of the biggest limitations today is context: how long a conversation can be.
It's not just about what's been said in a session. More things factor in. The relevant ones:
- How the agent is configured: system prompt.
- What tools it has available: reading a file, modifying it….
- What MCPs it has available: we'll get into detail shortly.
- What Skills it has available: we'll talk about this too.
And this is where MCPs have a big problem: they can end up consuming a lot of context.
For example, Claude Code has 14 native tools. Each tool takes up some context, since it needs to describe what it is, how it's used, and when it should be called.
The same applies to MCPs. One of the most popular is Playwright, used to control the browser. It currently includes more than 25 tools, and all of them are necessary:
- Navigating to a URL.
- Clicking on elements.
- Executing JS on the page.
- And much more.
Those 25+ tools consume a lot of context (perhaps 10% of the total available).
If you add more MCPs on top of that, you run out of context very quickly.
On top of this, agents can get confused and call the wrong tool.
For example, instead of opening a file, they call the browser to open a file. This makes the agent perform worse since it has to take extra steps to achieve the same result.
To combat this, most agent systems took 2 measures:
- Being able to enable and disable MCPs on the fly.
- Adding a tool to search for other tools. This way, all MCP tool definitions aren't loaded into the context initially. Instead, the agent dynamically searches for available tools.
With all this, MCP usage improved significantly. But in parallel, we realized something else.
Agents are VERY good at using the CLI
The most obvious example here is gh, GitHub's CLI tool.
At some point GitHub released their own MCP and it was one of the first ones everyone rushed to install. Until we realized that agents could do the same thing using gh, in a more efficient way (less token consumption) and faster.
This made us realize that many MCPs that were wrappers around CLIs didn't make sense. If you gave the agent direct access to the CLI, it worked much better and you removed a level of indirection.
But there was a catch: this worked for CLIs that models had been trained on, but not for new ones. This is where a new piece came in.
Skills
In short, a Skill is a markdown file with instructions. A way to provide context to our models, but simpler and easier to share between people.
With Skills, you don't need to create an MCP server to wrap a CLI tool.
Simply by documenting how it works in the Skill itself, agents will know how to use it.
For example, if models hadn't been trained to use gh, we could quickly create a Skill for it:
---
name: gh
description: Use the official GitHub CLI to create issues, PRs…
---
You have the `gh` CLI installed. To see its usage, run `gh --help`.
…
This way the agent would already know how to use all of GitHub's CLI tools.
Worth noting: the Skill also consumes initial context, but only the description field from the frontmatter. Much less than the description of each tool in an MCP.
The same applies to MCPs that were wrappers around HTTP APIs. You can create a Skill that explains what endpoints exist and how to use them.
So with all this, the question arises…
So do MCPs no longer make sense?
Seeing that they no longer serve as wrappers for CLIs or APIs, it might seem like they don't make much sense anymore, but that's not the case. There's still an interesting use case: Code Mode.
Code Mode is a pattern invented by Cloudflare (and also explored by Anthropic).
The idea: give the agent the ability to call huge APIs (hundreds to thousands of endpoints) without having to train a model for each one or expose everything in the context.
This is achieved by exposing 2 tools:
- Search:
- Searches the API's OpenAPI schema and finds which endpoint to use.
- It's a semantic search. For example, you say "I want to see what DNS records are in my zones" and it tells you which endpoints to use.
- It returns a JS schema so the agent can call the API.
- Since it's JS, calls can be combined.
- Execute:
- Code is sent to be executed on the server.
- That code runs in a sandbox.
- An example could be:
const zones = await cloudflare.zones.list();
const zoneId = zones[0].id;
const records = await cloudflare.dns.records.list({ zone_id: zoneId });
return records.filter((r) => r.type === "A");
The important thing here is that on my server I don't have any cloudflare library installed, but the agent knows it can use it dynamically and send that code to the MCP to get the expected response. All without having to know all the endpoints it has internally.
Now you might be wondering: This could be a Skill, right?
And that's actually a very good question since it might seem as simple as creating a markdown with the definition of those 2 endpoints and we'd be done.
In this case, Cloudflare folks also have their own Skill for it, although it's not based on these endpoints.
So what advantage does the MCP have over the Skill?
The advantage is what happens if my APIs' behavior changes.
What if they now add a third validate tool that needs to be called before execute. With the Skill, we wouldn't automatically know about the change.
This is where MCPs remain relevant. Their tool definitions are dynamic: they're loaded every time you query what tools are available. If something changes, the agent will always have the latest version.
With a Skill, you rely on having a system that keeps it updated. There's no standard for that yet.
Also, there are other advantages to using MCPs:
- If your API isn't 100% HATEOAS, it makes calling it easier.
- It easily allows adding restrictions. For example, a Postgres MCP that only allows read queries. If we tell the agent to use the CLI instead, we'd have to create a user with minimal permissions.
- It has native authentication. Better UX for sites that require login compared to CLI.
- MCP Apps let you integrate your own elements into other systems.
- It's likely we'll be talking more and more about WebMCP.
So yes, even though Skills have taken significant ground from MCPs, today they remain relevant.