MCP has a great advantage over agent using cli: MCP is much easier to secure so that it's hardwired that the agent can only call the pre-configured MCP server. We run our agents so that they don't have access to public internet, so they could not run any cli commands. It's all either built-in agent tools, or 3rd party mcp servers. The agents never have access to any credentials, which makes them much more safe to use than a claude code running in yolo mode with fetching random cli binaries from the web.

Totally agree, MCP is the WAP equivalent of mobile internet access.

MCP will definitely not die. It works, it makes things easier for non-technical people, and is extremely inefficient. You can build an entire industry around that.

I have some hope that this'll all lead to a revival of semantic web / microformats / etc. Why write an API when you can just add some markup to your existing API, which already looks like stuff that it was trained on, and won't fall out of sync (because you use it too)?

Soon, if you want the performance of your AI clients to improve (wrt. token count and understanding) you will start to customize the output of the MCP server for more synthetic data, different data types, more permissive inputs, etc. And since most your clients will be AI that might be your API that fall behind, and MCP that will be maintained.

That's at least my experience with my current project: the traditional json, coding oriented API feels out of place, I maintain it out of habit. The real API is the MCP server, which is not designed like a traditional API would; understandability of the output for an LLM prevails instead of searchng for exhaustiveness, orthogonality etc.

But then there is the other side that companies are adding MCP servers to stuff that has never had a public API.

MCP is a higher layer than your existing API.

It’s like saying APIs are dead because you can just use HTTP. They’re not the same thing, though of course you can hand-roll the higher layer in the lower one. It’s just more work, less standard, less valuable.

I don’t think models will ever prefer a low level API to a decorated index of API features and how to use them, same way developers will never prefer a list of HTTP endpoints and bespoke headers + query strings + POST bodies over a structured API.

> get out of sync with the real-world implementation

You are missing the point. When the API moves, the agent has to adapt. Are you rewriting its skills?

MCP provides the instructions. When the API moves, MCP adapts. You need to do nothing.

So, basically the exact opposite of what you are claiming

What we really should have is an aligned discovery protocol and a generic globally used sdk which handles negotiation.

You have a client, the client uses the SDK, talks to endpoint x. Endpoint x tells it very efficient that they are now talking protobuf and rpc over quick or http15 and thats it.

Why don't we have this? Right because of people.

Its always people problem.

MCP is now here, it might stay.

I usually just generate the MCP server spec from existing openapi/swagger spec, maybe with a filter to omit certain endpoints and so on.

> AI should not be using a protocol or set of instructions that is different from what humans have access to (know and use).

Should it? I think it can be very useful to constrain what your AI can do (e.g. read files but don’t delete them). MCP is a way to do that.

> temporary workaround

I've heard this one before

(Maybe it'll be the first time that a temporary workaround stays around longer than expected then)

Funny thing is that Claude knows the api of Atlassian better than the mcp they provide. Mcp is limited it doesn't have all api calls described.

That’s only true for the frontier. The moment you start looking at enterprise consumers of AI you’ll see slow monoliths that make decisions by committee and those committees often don’t even understand the tech they’re passing ruling on.

And you’ll also often see CISO-offices that are managed by checklists and yet more committees.

Asking for MCP access is generally easier than asking for an API for several reasons:

1. MCP supports OAuth, so your access conform with numerous CIS (et al) compliance checklists (short lived secrets, MFA, user-specific credentials, user access managed by centralised directory services and thus can have business rules applied, etc)

2. MCP is something a business can make a cooperate decision on. And then you can refer to that decision each time you need an access to new service. Whereas API access isn’t. In some cases APIs are governed by LLDs, and then you have an extra layer of “fun” having to update documentation to describe, in detail, the technical specifications too.

3. MCP defines the interaction better. If you need to request access to an API then the inevitable question from the committee is “where is this code running from?” and so on and so forth. Whereas saying “MCP access for AI to assist the project team with development” is a lot easier conversation to have.

In short: Enterprises are a very different beast to your average business.

Totally agree with you.

> The main reason is that it adds another layer (and human) that can, and probably will, get out of sync with the real-world implementation, whether that implementation is an API, web, or a CLI.

The menial task of updating the interfaces when the code changes is something AI should be really good at, so it's essentially little to no actual programmer time waste

> So the current situation is basically that I used Claude to write an MCP server on top of our API. And then I need to occasionally tell it update it match the public doc.

> And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net.

Updating MCP by AI is one time effort.

Having AI re-create what MCP would do for every piece of code that uses a service is massively wasted effort in comparison

It's not question of "model limitation" but of cost effectiveness.

You can build a MCP server in minutes these days to connect to a REST API. The friction is close to zero.

> So the current situation is basically that I used Claude to write an MCP server on top of our API. And then I need to occasionally tell it update it match the public doc.

> And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net.

My reaction to this is.. really? Presumably your API and API docs have a release process. Hopefully an automated one. Why isn't the "hey Claude, update the MCP server" step a part of it?

[dead]