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.
AI should not be using a protocol or set of instructions that is different from what humans have access to (know and use).
Sure, companies want to expose MCP servers because it is the cool thing to do right now.
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.
So MCP feels more like a temporary workaround for current model limitations.
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.
MCP allows you to easily separate API requests from their access tokens, so that the LLM only has access to the requests part. Giving an LLM CLI access removes all boundaries, anything goes.
EDIT: to add an example: I have a personal claw agent that I only use CLI, I don't care. But I'm also building an agent inside a company product, and there we use MCP all the way.
The point is that you still need to expose a shell or a wrapper around exec to launch those commands. That is t appropriate when I want to lock the model down to working entirely from a sandboxed environment and expose some basic tools which are not “entire posix user space”.
MCP servers are not dead, they’re just overused in contexts they don’t really make sense in.
Another examole which is trivial with MCP but hard with cli binaries: blocking certain commands, such as write operations from the agent. With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.
Access control is the operating system's job, and modern OSes already provide plenty of great tools for doing that.
Just use the existing sandboxing infrastructure like bubblewrap, seccomp, etc. I have way more faith in that than in something than some regex-based blocklist.
With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.
Nah. Just don't let your model do anything potentially destructive until three or four other models have vetted the proposed action.
Filtering individual commands can never provide more than the shallowest semblance of security. If a smart model is hellbent on deleting your production database, it will write its own Python program to do it if the usual commands are blocked.
It is crazy how the preferred way or securing AI are vibe coded MCP servers which at the same time do access control, credentials handling and HTTP server/client boilerplate. Want to use a new API: just vibe code a new MCP you won't fully review. It is hardly better than yoloing. The security critical parts needs to leave MCP and be integrated with, or be in front of, the API in a way humans will understand and review.
The parent suggests MCP as a way to secure credentials and enforce guardrails, and sibling comments iterate on this. I might be reading a bit between the lines with my comment, but did not intend to derail the discussion.
But the parent who suggested MCP for security didn't say anything about vibe coding it. The person who talked about vibe coding an MCP was the one saying MCP isn't very useful.
To be devil’s advocate: if you are just running commands with bash or power shell or the like there is no protection. You might have some rules that ban
It is. The issue is all the weird constraints that usually come up with it. Like I want to use my favorite code editor, I want easy copy and paste, or I can’t bother setting up a separate user account on my computer.
On unix, you can easily create a new user account, switch to it (or ssh or setup vnc), and run the tool there. If users are enough for servers on the internet, they can be for your workstation (unless there’s something like copyfail, but you can make do with a vm then).
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.
Interesting points. A couple of questions. Do you have a frontend (React, Vue, anything) and if you do, does it interact with the server using the MCP server or the JSON API? Are all your clients AIs or do you expect that most of them will be AIs?
The reason I'm asking those questions is that a customer of mine has a service with a JSON API, a Vue frontend and a score of customers using that JSON API. We know that the newest ones are using bots to code their clients (and they are using them wrong, by the mistakes they do.) I don't see a near future in which all those third party apps become LLMs that would benefit from a MCP server and we retire the API.
I do have a front-end, but it interacts with the server with a specific, private API. It's using a more compact data encoding than JSON optimised for streaming the data that's needed for the front-end.
But yes I agree with your point: for a simpler app with a more traditional web UI it's likely the API used by the front-end would largely overlap with the user-oriented API. Then indeed the REST API has to be maintained for as long as humans continue to use the front-end.
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)?
> I have some hope that this'll all lead to a revival of semantic web / microformats / etc
Why would it? Do you see any agents or models use that? No, instead vibe coders at Anthropic vibe-designed a bespoke protocol that sidesteps and ignores the last 60 years of API development and integrations.
SW is about data interchange and standardizing semantic representations… it relies on formal, structured taxonomies of All The Nouns and then All The Verbs For Those Nouns.
MCP is structured at the protocol level, but its whole value is the bridge from structured to unstructured: natural language agent intents to specific APIs, domain-specific data to fuzzy natural language.
Semantic Web only works if someone has clearly defined the domain you want to operate in. MCP can work without that kind of definition (an API or prompt needs to exist, but it doesn’t need to be modeled in any way similar to RDF)
> What are you talking about?!
For instance, MCP-to-SPARQL bridge[2] that lets agents query SW data.
That was exactly my thought when I saw MCP: like we know so much about creating protocols but get a bunch of people together with no experience and that’s what you get.
Reminds me a lot of Microsoft’s WS-disaster of the early 2000s except the latter was thought through a little better.
To be fair a while back I did design an API for a general purpose model trainer which was absolutely atrocious for a few reasons, my own ignorance was a factor but the problem of accommodating everything from “model that can be trained in 30 seconds on a small machine” to “model that takes 30 days of training on a cluster” problematized it.
It would have made so much more sense to build a standard for documenting ordinary API endpoints and CLIs.
I definitely see it going that way from a marketing perspective if you want what you send/produce to be machine readable and actually used in intermediated surfaces like email and web search.
They are building them because they can ask an AI to spin it up. They could have asked it to spin up the public API just as easily. The MCP choice is a fashion choice vs an openapi spec with similar documentation (or any number of other human+machine readable tooling). It might accidentally win or accidentally lose just because of the timing / network effects.
I haven't found this to be the case. I tried to make `acli` work, with CLAUDE.md fine saving the things Claude learns about how to use the API (eg which custom variables to include and so on), but in the end found the MCP to work better. I think I had trouble getting the CLI to update a certain custom field, which the MCP was able to do. Not to mention, I don't think `acli` even works with Confluence?
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.
> 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.
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.
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.
Here is my vision: the future of AI is about truly understanding the real world. The world around us.
Not everything in the real world will expose an MCP server so AI can interact with it.
Eventually, AI will need to move beyond MCP and interact with the real world the same way humans do: by observing, interpreting, reasoning, and taking action in messy, imperfect environments.
MCP tries to organize our messy word to make interaction part with the world easier in the near term, and it will help accelerate very early progress. But ultimately, MCP is a temporary bridge. Not the final destination.
The problem isn’t that AI cannot do this already. Because it can. The problem is cost.
There are people complaining that MCP costs too many tokens. Parsing the same UIs that humans do would just be insane.
And to be honest, I don’t think that’s the right goal of AI anyway. Most competent engineers prefer APIs to human interfaces. So why should machine-to-machine use that too?
Easy. What a cron script (that runs as root) that populate a maildir that the agent (restricted user) has access to. The. you restrict network access to the internet, and have it send you its findings by mail (local mail server).
If you don’t know how to keep your openapi spec up to date then yes you’ll struggle with keeping an MCP up to date. At the end of the day, keeping APIs in sync with SDKs, documentation, MCPs is a solved problem through automation. It’s not hard.
> 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?
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.
Right; isn't this already captured by an openapi spec with RBACs? Plus the benefit that your ai agent can keep using all the pre-AI tools that already interface with those specs. What is MCP bringing that an openapi spec doesn't?
You can build an MCP client really really easy today with libraries and it integrates with inference calls very well. If you want to give a cloud agent access to another api, you need to bills a connector or give it shell access or some sort of sandbox with tools to access that stuff. That’s fine, but how do you then give it auth access? How do you ensure security boundaries? MCP builds those in and the shape (prompts, resources, tools, etc) are good for agentic work.
It’s like asking why we needed browsers when we had BBSes; they serve a different but similar purpose and are build on different abstraction levels.
So this is basically the EU version of Zelle? Basically a way to transfer money between parties who already have established trust. Am I understanding that correctly?
But I am confused about how this relates to Visa and Mastercard. Those systems are used for payments between parties that have not necessarily established trust.
Yes, but more importantly, it's essentially the EU version of Alipay (which can be used for merchant payments as well as P2P transactions).
P2P payments, specifically SEPA Instant bank transfers, have already been instant and free for several years now in the EU, so there's no need for a Zelle alternative (other than maybe for contact discovery without IBAN).
And speaking of Alipay: This is the actual global alternative to Visa and Mastercard that almost nobody in the west is talking about or even aware of. While it used to be mainly used by either inbound or outbound tourists in/from China, it now spans many countries and issuing and merchant banks all over the world, including many in Europe. Wero is many years behind in that regard.
It's a an all-in-one kind of system where you have p2p payments and traditional online payments (like what you would do when making payment for a product on some e-commerce shop).
Plus some additional features like payments through QR.
Yes Wero and Zelle are similar: real-time payment systems, where money is sent directly from bank account to bank account, and recipients are looked up with a convenient ID (a phone number, or an email).
From what I know this is going to be challenged in the court and it probably it is not going to pass the legal challenge (renting part is one interesting loophole - I think that one caused similar tax law in SF to be struck down).
I assume this will be challenged in court immediately. Does anyone understand whether it is likely to survive those legal challenges?
EDIT:
Here is a list reported by Google search but I really do not understand or know how reasonable these challenges are.
Equal Protection: Owners may argue the tax unfairly treats similar properties differently based on second-home status, value threshold, or owner residence. This is likely a weaker challenge because tax classifications usually receive deferential rational-basis review.
Nonresident Discrimination: A challenge could claim the tax targets out-of-city, out-of-state, or foreign owners rather than property use. The law is safer if written as a tax on non-primary luxury residences, not on nonresidents as a class.
Assessment Inequality: Owners may challenge how the city values condos, co-ops, townhouses, and mixed-use properties. This could be significant if the $5 million threshold is applied inconsistently or without reliable valuation rules.
Due Process: Owners may argue the law lacks clear notice, proof, exemption, and appeal procedures. This would be especially relevant for disputes over whether a home is truly a second home.
Residency Conflicts: Taxpayers may challenge inconsistent treatment if the city treats them as NYC residents for income tax but non-primary homeowners for this tax. Clear coordination between residency rules would reduce this risk.
Home Rule Authority: Opponents may argue NYC lacks authority unless the state clearly authorizes the tax. This challenge is less likely to succeed if Albany passes valid enabling legislation and NYC follows required procedures.
Property taxes already exist. There is no obvious reason why this particular property tax would be legally problematic.
The tax is also likely politically difficult to counter. Consider how limited in scope these taxes are, how the tax revenue benefits residents who live in NYC through providing more revenue for services without taxing residents at all, and how the only constituent the taxes negatively affects are non-residents (aka it’s non-trivial to argue that these people should even be considered constituents) who benefit from the services the city offers through stable apartment prices that nicely store their wealth yet provide little value in return.
The only rebuttal one could conceive is the value these high-net-worth individuals altruistically provide the city through developing office space and giving jobs to the city is not worth risking, but that is like saying the tail wags the dog. The reason these CEOs go to NYC is because that is where the talent and economic clustering is: if these high-net-worth individuals could get the talent they need to run their firms in Miami and Austin, they would have done so already. They have tried and they have failed up until this point.
Regardless, a claim into the future in such a complex system such as the markets and the judicial system (especially a common law system) always relies on induction which is never going to be deterministic. However, this tax is just another property tax meaning it likely will stand in court. Additionally, given that the opposition has very weak rebuttals against a well-versed counterparty implies the legislature or other political machinery won’t have a strong enough incentive to fight this tax.
>The reason these CEOs go to NYC is because that is where the talent and economic clustering is: if these high-net-worth individuals could get the talent they need to run their firms in Miami and Austin, they would have done so already. They have tried and they have failed up until this point.
This needs to be shouted from the rooftops.
I am from NYC and live in Miami.
I have seen hedge funds try and fail to bring talent down here, and paying talent through the nose to convince them. It has failed, because 1. local private schools won't let Ken Griffin buy his way to the front of the line; and 2. there's no local talent pipelines to recruit from that come even remotely close to what is found in the Northeast, or in the Bay Area.
UM pales in comparison to the fact that almost every Ivy League school is within a 3 hour drive of NYC, not counting other strong school (NYU, NEASC colleges, MIT, etc). FIU or UF isn't even in the same stratosphere.
Taxes pay for the establishment of a strong educational foundation so that even local public schools can send kids to Ivies or top colleges. Taxes pay to keep that going.
NYS already has tax breaks for one's primary residence which varies by income and a tax on the sale of homes >$1Mil. Given how entrenched those are, I have trouble imagining a way in which this new tax is incongruous with existing rules.
But that is a the problem though. You get stronger job protection because its very hard to find a job. If you could find a new job quickly and if the job market was more fluid, you would only rarely need this sort of job protection.
Compared to what I have heard about the US, I'd say it is actually easier to find jobs in (at least Western) Europe. Plenty of jobs, and a way easier interview process. Not 8 rounds of interviews and months of waiting (that I've heard of). But maybe two rounds in the same week and start the next month (if you want).
I think parents are raising the alarm about nefarious social media practices (ie recommendation algorithms that actively do harm) and those services are in turn pushing these controls in order to deflect responsibility away from themselves.
There’s an alternate view that parents are very much in support of centralized policy. When policy is left up to individual families — little Johnny X has an iPhone but little Timmy Y doesn’t — the creep towards everyone having a phone begins. When, instead, the school board bans phones it’s much easier for the conservative majority of parents to hold the line.
Banning phones at school has nothing to do with freedom to use phones. You are not restrained in your freedom because using you smartphone while driving is forbidden.
Kids go to school to learn, not to watch modern cable shopping network (aka Tiktok/Instagram).
Sadly, this is how societies eventually tend to become. They need the younger generation to be “properly” raised (definition of “proper” really depends on the society).
If the side effect is that you also end up controlling adults and making them behave “properly,” then that is considered a plus.
That is the simple explanation.
reply