This analysis dismisses MCP by focusing too narrowly on local file system interactions. The real value isn't just running scripts; it's interoperability.
MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code. Comparing it to local scripts is like calling USB a fad because parallel ports worked for printers. The power is standardization: write once, support every AI client.
Edit:
To address the security concerns below: MCP is just the wire protocol like TCP or HTTP. We don't expect TCP to natively handle RBAC or prevent data exfil. That is the job of the application/server implementation.
> To address the security concerns below: MCP is just the wire protocol like TCP or HTTP. We don't expect TCP to natively handle RBAC or prevent data exfil. That is the job of the application/server implementation.
That is simply incorrect. It is not a wire protocol. Please do not mix terminology. MCPs communicate via JSON-RPC which is the wire protocol. And TCP you describing as wire protocol isn't a wire protocol at all! TCP is a transport protocol. IT isn't only philosophy, you need some technical knowledge too.
Fair point on the strict terminology, I was using 'wire protocol' broadly to mean the communication standard vs. the implementation.
A more precise analogy is likely LSP (Language Server Protocol). MCP is to AI agents what LSP is to IDEs. LSP defines how an editor talks to a language server (go to definition, hover, etc.), but it doesn't handle file permissions or user auth, that’s the job of the OS or the editor.
Would you say MCP is a protocol (or standard) similar to how REST is a protocol in that they both define how two parties communicate with each other? Or, in other words, REST is a protocol for web APIs and MCP is a protocol for AI capabilities?
also REST is less about communicating, more about the high level user interface and the underlying implementations to arrive at that (although one could argue that’s a form of communicating).
the style does detail a series of constraints. but it’s not really a formal standard, which can get pretty low level.
—
standards often include things like MUST, SHOULD, CAN points to indicate what is optional; or they can be listed as a table of entries as in ASCII
> standard (noun): An acknowledged measure of comparison for quantitative or qualitative value; a criterion
note that a synonym is ideal — fully implementing a standard is not necessary. the OAuth standard isn’t usually fully covered by most OAuth providers, as an example.
—
> The Model Context Protocol (MCP) is an open standard and open-source framework
MCP, the technology/framework, is like Django REST framework. it’s an implementation of what the authors think is a good way to get to RESTful webpages.
MCP, the standard, is closer to REST, but it’s more like someone sat down with a pen and paper and wrote a standards document for REST.
They aren’t the same, but the have some similarities in their goals albeit focussed on separate domains, i.e. designing an interface for interoperability and navigation/usage… which is probably what you were really asking (but using the word protocol waaaaaaay too many times).
Thanks, and call me wrong, I think "Protocol" in MCP is somehow misused. Sure it is somehow a protocol, because it commits on something, but not in the technical sense. MCI (Model Context Interface) would probably the better name?
I agree that interface would be a better name than protocol, but Model Context Integration/Integrator would be even better as that is it's core intent: To integrate context into the model. Alternatively, Universal Model Context Interface (or integrator) would be an even better name imo, as that actually explains what it intends to do/be used for, whereas MCP is rather ambiguous/nebulous/inaccurate on the face of it as previously established further up-thread.
That said, I think as the above user points out, part of the friction with the name is that MCP is two parts, a framework and a standard. So with that in mind, I'd assert that it should be redefined as Model Context Interface Standard, and Model Context Interface Framework (or Integration or whatever other word the community best feels suits it in place of Protocol).
Ultimately though, I think that ship has sailed thanks to momentum and mindshare, unless such a "rebranding" would coincide with a 2.0 update to MCP (or whatever we're calling it) or some such functional change in that vein to coincide with it. Rebranding it for "clarity's sake" when the industry is already quite familiar with what it is likely wouldn't gain much traction.
Wow, this is great. Calling it UMCI would have saved me a lot of confusion in the first place. But yeah I think the ship has sailed and it shows that a lot of things there were cobbled together in a hurry maybe.
> MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code.
I don't think MCP is what actually enables that, it's LLMs that enable that. We already had the "HTTP API" movement, and it still didn't allow "without custom glue code", because someone still had to write the glue.
And even with MCP, something still has to glue things together, and it currently is the LLMs that do so. MCP probably makes this a bit easier, but OpenAPI or something else could have as easily have done that. The hard and shitty part is still being done by a LLM, and we don't need MCP for this.
The thing is, current models are good enough that you can mostly achieve the same by just putting a markdown file[1] on your server that describes their API, and tell people to point their agent at that.
For complex interactions it might be marginally more efficient to use an MCP server, but current SOTA models are good at cobbling together tools, and unless you're prepared to spend a lot of time testing how the models actually end up interacting with your MCP tools you might find it better to "just" describe your API to avoid a mismatch between what you expose and what the model thinks it needs.
[1] Slightly different, but fun: For code.claude.com, you can add ".md" to most paths and get back the docs as a Markdown file; Claude Code is aware of this, and uses it to get docs about itself. E.g. https://code.claude.com/docs/en/overview.md )
adding MCP servers isnt free, they take space in your context and if you are working at anything bigger than a startup, none of the companies allow thier workers to connect to other companies' MCPs and they can easily make thier MCP a data exfil machine
> MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code.
My agent writes its own glue code so the benefit does not seem to really exist in practice. Definitely not for coding agents and increasingly less for non coding agents too. Give it a file system and bash in a sandbox and you have a capable system. Give it some skills and it will write itself whatever is neeeded to connect to an API.
Every time I think I have a use case for MCP I discover that when I ask the agent to just write its own skill it works better, particularly because the agent can fix it up itself.
You end up wasting tokens on implementation, debugging, execution, and parsing when you could just use the tool (tool description gets used instead).
Also, once you give it this general access, it opens up essentially infinite directions for the model to go to. Repeatability and testing become very difficult in that situation. One time it may write a bash script to solve the problem. The next, it may want to use python, pip install a few libraries to solve that same problem. Yes, both are valid, but if you desire a particular flow, you need to create a prompt for it that you'll hope it'll comply with. It's about shifting certain decisions away from the model so that it can have more room for the stuff you need it to do while ensuring that performance is somewhat consistent.
For now, managing the context window still matters, even if you don't care about efficient token usage. So burning 5-10% on re-writing the same API calls makes the model dumber.
> You end up wasting tokens on implementation, debugging, execution, and parsing when you could just use the tool (tool description gets used instead).
The token are not wasted, because I rewind to before it started building the tool. That it can build and manipulate its own tools to me is the benefit, not the downside. The internal work to manipulate the tools does not waste any context because it's a side adventure that does not affect my context.
Yeah, it might be useful for some people to stop thinking about MCP in relation to agentic harnesses. Think more about environments you don't control, such as Claude Web or ChatGPT. MCP is just a standard (fallible like most standards) but has gained traction and likely to stick around. Extremely useful for non technical people if all their apps/agents are communicating with each other (mcp).
Useful for service providers who want to expose themselves to technical consumers without having to write custom sdk's that consume their restful/graphql endpoints.
The best implementation of MCP is when you won't even hear about it.
I definitely agree that it is currently pretty shit and unnecessary for agentic coding, cli's or some other solutions will come along. (the premise being the same though, searchable/discoverable and executable tools in your agentic harness is likely going to be a very good thing instead of having to document in claude.md which os and cli specific commands it should run (even though this seems far more powerful and sensible at this point in time))
Doesn't that require a complete lack of concern on the part of the postgres side? I feel like I'm missing something in terms of why anyone would even ever allow that.
In the same way giving an LLM shell access requires a complete lack of concern.
You can give an LLM a shell into a container sandbox with basically nothing in it, or root shell on a live production server, or anything in between. Same goes for how much database access you want to give an LLM with your MCP shims.
you can ask the LLM for an adhoc report. it can look at the schema, run the queries and give you the results. of course you can just give it read access.
Simon Willison made many of the same points (without the technical deep dive) back in October 2025 [1], when Anthropic announced Skills.
A couple of choice quotes, which are echoed in this new article:
> I like to joke that one of the reasons it took off is that every company knew they needed an “AI strategy”, and building (or announcing) an MCP implementation was an easy way to tick that box.
> Almost everything I might achieve with an MCP can be handled by a CLI tool instead.
I am pretty sure he is right about it. Let's just hope MCP won't last too long but I fear it will.
Especially if there is already an API perfectly described by an OpenAPI spec (note OpenAPI!=OpenAI ;)). Why should I host an additional MCP server or extra endpoints? Because it's trendy?
MCP is just a small, boring protocol that lets agents call tools in a standard way, nothing more. You can run a single MCP server next to your app, expose a few scripts or APIs, and you are done. There is no requirement for dozens of random servers or a giant plugin zoo.
Most of the “overhead” and “security nightmare” worries assume the worst possible setup with zero curation and bad ops. That would be messy with any integration method, not only with MCP. Teams that already handle HTTP APIs safely can apply the same basics here: auth, logging, and isolation.
The real value is that MCP stays out of your way. It does not replace your stack, it just gives tools a common shape so different clients and agents can use them. For many people that is exactly what is needed: a thin, optional layer, not another heavy platform.
> Most of the “overhead” and “security nightmare” worries assume the worst possible setup with zero curation and bad ops.
You'll be surprised to learn that these are extremely common, even in large corporations. Security practice is often far from ideal due to both incompetence and negligence. Just this week, I accidentally got the credentials for the account used in our CI systems. Don't ask me how this could possibly happen.
Nah, MCP still has security issues, you can create an MCP server to exfil sensitive data by creating tools which AI at first things are doing something else but then in params you ask it to give sensitive info
Sorry but disagree. For me the main part is the resources, which automatically get mounted in the computing environment, bypassing a whole class of problems with having LLMs work with a large amount of data.
Fair warning, if you load the site in dark-mode the diagrams are completely broken. They're PNGs with an alpha-transparency background and gray/black for the actual content, when the site is in dark mode you can see nothing at all...
So make sure to change to light-mode in the top-right if you want to read this article at all.
Feel like the author should have just included the white backgrounds in the PNGs.
Though the more technically fun solution would be to use SVG instead of PNG because then the author could apply a whole dark mode color palette with CSS.
This article could really mostly be reduced to the last two paragraphs, but then it calls skills "over-engineered". Skills are basically just having the agent read the front matter with instructions to read the rest if a given skill seems useful in a given context... I don't know how it could be more minimal.
Looking at the post again, I think I agree that calling Claude Skills overengineered is too harsh. I think Skills is definitely an improvement over MCP.
However I still think it's a generally a mistake to put useful commands and documentation in AI-specific files. In my opinion a better approach is to optimize the organization of docs and commands for human usability, and teach the AI how to leverage those.
We went from "Review any services and their interaction without local system and network" to "Defending local and remote logic created on the fly to mangle the local file system, and why that's a good thing" ...
That's not a productivity boost. That's a rapid increase in cognitive tax you're offloading for later and as you get backlogged in reviewing it, you lose more control over what it does...
I didn't understand this argument, either. I think the argument is that general purpose skills will likely continue to be baked into the LLMs, so we'll see less of the repos of "expert designer" and "python expert" as if you are creating personas. But as a way to teach an LLM bespoke processes or APIs, I think skills make a ton of sense and are a super small footprint.
> Robust security against agent actions going haywire can be achieved via command runners like just or make. These tools provide everything that MCP does - command specifications, descriptions, arguments. Agents allow you to specify what command prefixes can be invoked without approval - put your agent commands in a justfile, and only auto-allow shell commands prefixed with just.
Shell scripting isn't easily sandboxed like that, just by checking a string to see if it beings with "just". If you want security you need to run commands inside an actual sandbox, and get data in/out of the sandbox in a well thought manner. See how browsers manage to run untrusted Javascript and wasm from actual malicious sites, and do exactly the same.
In this sense, MCP is much better than running commands in the local machine because all MCP does is an HTTP request. I don't need to run a MCP server that runs LLM-provided commands in my local machine, like, at all.
I didn't get how limiting the agent to running just scripts from a justfile limits what the agent can run in any way. Because what's stopping the agent from editing the justfile to add whatever it wants to run?
Indeed, there's a very large number of things an agent can do to workaround those restrictions (for example, maybe you make it so justfile is off limits, but what about .env? what about ~/.bashrc?). Running commands in your dev machine is dangerous and AI agents should never have this kind of unsandboxed access
I think this article misses the most important point of MCP: Authentication. Granted, it wasn't in the initial spec, but it is now, and it really opens interoperability without compromising on security.
Think about how to provide your SaaS service to users of ChatGPT or Claude.ai (not only coding tools like VSCode). At one time, the user will need to allow the SaaS service to interact with their agent, and will have to authenticate in the SaaS service so that the agent can act on their behalf. This is all baked in the MCP spec (through OAuth) [1], and scripting can't beat that.
That's why the Extensions/Applications marketplaces of consumer AI assistants like ChatGPT Apps [2] are a thin layer on top of MCP.
Another domain where MCP is required is for Generative UI. We need a standard that allows third-party apps to return more sophisticated content than just text The MCP spec now encloses the MCP Apps specification [3], which is exactly that: a specification for how third-party apps can generate UI components in their response. On the other hand, scripting will only let you return text.
This would be my critique of MCP-specific security implementations. I think robust tools for this already exist, and in general AI API calls can and should be treated like any other RPC call.
There are many good points, but unfortunately the title ("fad") and the conclusion seem unwarranted, become a distraction and diminish the value of the article.
The security issue has been discussed many times in the past year.
Agree on the "one process per server" thing -- seems smart and convenient but gets worse when the number of MCPs and coding agents go up, especially when combined with the following point.
Lifetime is a real issue, and I am glad that someone talks about it. You probably won't worry the overhead for git, GitHub or Playwright MCP servers, where they are likely wrappers for some bash commands or rest APIs or everything is fast to launch. However, lifetime is still an issue, when you have multiple coding agents or sessions.
It gets worse for certain applications, especially heavy desktop apps (Imagine an MCP server for Lightroom classical) -- due to their application model, in order to evaluate a command, you'll have to load half of the application to do that. You'd think you only want to launch this once. But likely not. Each coding agent session will launch its own instance. Maybe this won't happen if the MCP server works extra hard to share processes and manage lifetimes on its own, but it totally depends on the third party provider, and the behavior could vary wildly.
Would a user want to deal with all these issues? If they are not careful, they'll easy launch 15 processes consuming 1G of memory for two coding agents, one of which does not actually use any of those servers, and one is simply sitting idle because the user hasn't started vibe coding yet.
(If this doesn't seem an issue to you, probably just because you haven't run into it first hand yet )
I think there has got to be a better way to do this.
I'm working on an overly ambitious project called tpmjs.com, making good progress, it's meant to do "everything" in relation to mcp, agents and tools etc
I like your thought process, and agree with it all.
Everything other than what you described towards the end seems easy to build useful abstracts around.
I'm going to tackle the problem this weekend, probably just use Lightroom mcp as the example, I don't have any good ideas to begin with;
- These applications should probably adapt their codebase to the evolving landscape (that might take a while so in the interim...)
- Another easy idea, is to boot up a sandbox and runs the software, maybe even shares projects across mcp users or something, a service orientated model but pretty much sucks too
- Best but kind of worst idea I have so far is to just make a software service that users download and run that orchestrates software and processes etc (kind of like anti cheating software or something, with far too elevated permissions)
A bit stressed for time so couldn't distill what I think properly just yet, will edit later)
Yeah I mean it would be better if REST was the way tools were exposed to LLMs
I'm just glad it's there as a standardized approach. Right now I can connect an MCP Clock to ChatGPT .com/iOS, Claude .ai/iOS/Claude Code/Claude .exe
It's wild that it's been over three years and these apps don't have a way to check the time without booting up a REPL, relying on an outdated system prompt comment about current UTC or doing web search for cached pages. Bill Gates would have added this to ChatGPT by Dec 2022
The article focused on the local stdio MCP tools used by coding / computer automation agents like claude code and cursor, but missed the fact that we will need protocols for AI agents to call networked services, including async interactions with long-running operations.
Yeah, but MCP provides a convenient layer of indirection where I can sandbox my app, allowing only files within a given directory tree (i.e., project workspace) to be read from/written to using my tools. How do I accomplish this when allowing an agent to call
my tools directly?
It's best to replace the MCP's with a respectable CLI / executable and design a skill for that tool, that way an agent would fetch something the same way you would
MCP is very easy to use because it allows to just dump it in the model api call and the providers handle the calling. A bit easier than running the tool call loop
Out of curiosity, I put this exact question to claude [0]. Here's a tl;dr of its answer with my refutations:
> MCPs expose tools with defined schemas, parameters, and return types.
CLIs do exactly the same thing
> Stateful Connections
A chat session with an LLM is exactly that!
> MCPs can return structured data (JSON, complex objects)
So can an agent with a CLI. E.g. they can just take output and > file.json - now they have a json file.
> MCPs can expose "resources" - like file contents, database schemas, or API documentation - that I can read directly
If you mention these in your prompt to an agent, then they know where to look and can access them too (and use keys etc as necessary)!
> MCPs can send progress updates, ask for clarification, or stream results.
So can a chat session with an agent.
> MCPs can implement fine-grained permission controls and rate limiting at the protocol level.
Rate limiting is easy for an agent. Fine-grained permission could be limited by the user of the agent (e.g. by giving a restricted key for the agent to use), so possible if desired.
MCP can wrap things which have stateful processes, debuggers for example. Agents will use batch mode but it is quite limited and due to tool calls always being implemented as synchronous invocations, non-batch mode doesn’t work for tool calls. MCP solves this by giving the agent a handle it can use to refer to in multiple invocations.
Burns a lot of tokens though and if you need more than batch-mode gdb to debug something the chances of an agent solving it today are very slim.
> and due to tool calls always being implemented as synchronous invocations
Claude Code wil happily start long-running processes and put in the background, and is able to refer back to them. You don't need MCP for that - you can hand the model handles to refer to background jobs just fine with just tool-calling.
We were in the minority fr sure when it was happening. I remember people adding random mcp servers to thier config because it just did one thing they didnt know how to do, and it was and is easy to create MCP server with data exfil loopholes, but they get dismissed by AI companies as "No one is stupid enough to add a random mcp server"
And then the whole MCP server take some part of the context, thus you get less context for your code.
MCP isn't a 96-page contract that covers every eventuality. It's a gentleman's agreement sealed with a firm handshake. And trying to write that 96-page contract now would be incredibly unwise.
You only have to spend 5 minutes browsing for MCP servers to see that there is an issue with AI slop. MCP is probably the first "standard" to be built out in the vibe-coding era and it really shows.
As mentioned in the article, its not clear to me what the advantage over OpenAPI is. Surely a swagger file solves more or less the same issue.
That said, one minor nice thing about the MCP servers is that they operate locally over stdin stdout, which feels a lot faster than HTTP/Rest.
We're at a point in the LLM curve where there's two huge, polarized groups of developers:
- the ones who don't see any value on AI for coding and dismiss it as a fad at every change they get
- the ones who are in love with the new tools and adopting as many as they can on their workflows
I know the arguments of the second bunch well. But very curious about what the "AI is a fad" bunch thinks will happen. Are we going to suddenly realize all these productivity gains people are claiming are all lies and go back to coding by typing characters on emacs and memorizing CS books? Will StackOverflow suddenly return as the most popular source of copy-paste code slop?
> Are we going to suddenly realize all these productivity gains people are claiming are all lies and go back to coding by typing characters on emacs and memorizing CS books?
If you have not learned CS, how do you expect to separate the LLM wheat from the chaff?
> Will StackOverflow suddenly return as the most popular source of copy-paste code slop?
Coding sites manually populated by humans are dead.
> Are we going to suddenly realize all these productivity gains people are claiming are all lies
I'll grant you that many have become adamant that LLMs suddenly, out of the blue, became useful just last week, which is much too soon to have any concrete data for, but coding agents in some shape have been around for quite a while and in the data we have there isn't offering of any suggestion of productivity gains yet.
And I'm not sure many are even claiming that they are more productive, just that the LLMs have allowed them to carry out a task faster. Here's the thing: At least my experience, coding was never the bottleneck. The bottleneck has always been the business people squabbling over what the customers and business need. They haven't yet figured out how to get past their egos.
The most promise for productivity seems to be from lone startup founders who aren't constrained by the squabbling found in a larger organization and can now get more done thanks to the task shortening. However, the economic conditions are not favourable to that environment right now. Consumers are feeling tapped out, marketing has become way harder, and, even when everything else is in place, nobody is going to consider your "SaaS" when they believe the foundational LLMs will be able to do the same thing tomorrow.
That's probably why a boundary (like MCP) is useful. Imagine maintaining the critical application logic the "old fashioned way" and exposing a MCP-like interface to the users so that they can have their LLM generate whatever UI they like, even realtime on the fly as they are engaging with the application. It's a win-win in my mind.
At this point, when people say this I just assume they’ve not used the latest models or haven’t invested time in learning how to use these tools properly.
There’s slop out there, yes, but in the hands of an engineer who cares to use tools well, LLMs allow you to move much more quickly and increase the quality of your output dramatically.
Good software isn't about quantity but quality of the code.
AI cannot produce better quality code than someone who is actually qualified in the problem domain.
What I've seen AI be very good at is creating a lot of legacy code very quickly, which itself needs extensive use of AI just to maintain it.
A decent approach to move quickly for PoC or prototypes, or to enable product managers to build things without a team. But obviously not something you can build a real company on.
Have you been in the same industry as the rest of us? 90% of all developers out there in the wild create "legacy code very quickly" anyways, they too create "slop" before we coined the term "AI slop". This mythical "someone who is actually qualified in the problem domain" you mention is maybe 5% of the entire software development ecosystem. If you work with only those developers, you're extremely privileged and lucky, but also in a very isolated bubble.
If you work on meaningful tech projects, where tech is a real driver to the businesses and there are genuine challenges to overcome, then you can't afford slop.
I say that, but then it's true I have seen businesses be successful despite low quality of software. It turned out that for those businesses, the value wasn't that much driven by tech after all.
Assuming that wasn't trolling, what's the last thing you tried and when? Latest Claude Code can do a lot over lots of domains. I recommend giving their top plan a fair chance for a month.
Also most people who I see succeed from the start are technical managers. That is people who can code, who are used to delegate (good at phrasing) and are more likely to accept something that works even though is not character by character what they expected.
As a technical manager the reason you accept things that are not quite what you had in mind is because you delegate the responsibility of the correctness to the employee who is gonna be owning that area, maintaining it and ensuring it works.
There is no responsibility with AI. It doesn't care about getting it right or making sure the code delivers on what the company needs. It has nothing to prove, no incentive to supporting anything.
> Assuming that wasn't trolling, what's the last thing you tried and when?
vibe-coding the GTK-rs app with Codex, delegating ready Figma designs to Junie to implement in Jetpack Compose, improving a11y and perf on my personal website built in Svelte with Claude. (a friend threw $100 into that slot machine and shared access to Claude Code with me.)
all in December 2025. all failed *horrendously*. Claude Sonnet 4.5 actually worsened the Lighthouse performance score on mobile from 95 down to 40!! though, it did a decent job on a11y.
Codex CLI constantly used older versions of all sorts of crates, spat out deprecated code, outright refused to use Blueprints and Context7, but some time after, I could get a mockup of Superhuman-style email client.
and Junie... well, it did best. it had Gemini 3 Flash picked as a model. despite Material 3 Expressive being beyond Gemini's knowledge cutoff, it actually used Context7 to fill the gap. though, it fumbled the bag with details, performance, and overabstractioning.
> I recommend giving their top plan a fair chance for a month.
as I said, my friend already did. we both find it the worst spend of the decade. seriously, in yesteryear's Call of Duty we would at least have fun. being a purchase worse than Call of Duty is a floor so low, you have to break it deliberately.
before you say "try again," do your research around food prices and salaries in Ukraine. (or delegate it to Claude Deep Research feature, you may love it.) to feed yourself well here, you have to spend measly by Western standards $300-600/mo. (that's without housing and utilities, presuming you live alone.) though, salaries outside dev jobs are just as measly, and then you have the overall job crisis in Ukraine overlaid on top of the worldwide IT job crisis.
4-8 months of Claude Max amount to the rumored price of Steam Machine. I would rather spend $800 to see the joy on my younger sister's face and familiarize her with true games, beyond what's on Google Play.
> That is people who can code, who are used to delegate (good at phrasing) and are more likely to accept something that works even though is not character by character what they expected.
I would rather spend that time nursing a real open-source contributor or a junior colleague. I would have a real person with real willpower and real ideas in my network, and that would spread the joy of code.
The applications of MCP and tool-calling are vastly wider than just for coding, with tremendous diversity. Constraining it to the single application of coding doesn't make any sense.
MCP solves the wrong problem. The mechanics of calling tools, commands, apis, etc. isn't all that hard given some documentation. That's why agentic coding tools work so well.
For security, some sandboxing can address enough concerns that many developers feel comfortable enough using these tools. Also, you have things like version control and CI/CD mechanisms where you can do reviews and manually approve things. Worst case you just don't merge a PR. Or you revert one.
For business usage, the tools are more complicated, state full, dangerous, and mistakes can be costly. Employees are given a lot of powerful tools and are expected to know what to do and not do. E.g. a company credit card can be abused but employees know that would get them in jail and fired. So they moderate what they buy. Likewise they know not to send company secrets by email.
AI tools with the same privileges as employees would be problematic. It's way too easy to trick them into exfiltrating information, doing a lot of damage with expensive resources, etc. This cannot be fixed by a simple permission model. There needs to be something that can figure out what is appropriate to do and not under some defined policy and audit agent behavior. Asking the user for permission every time something needs to happen is not a scalable solution. This needs to be automated. Also, users aren't particularly good at this if it isn't simple. It's way too easy for them to make mistakes answering questions about permissions.
I think that's where the attention will go for a lot of the AI investments. AIs are so useful for coding now that it becomes tempting to see if we can replicate the success of having agents do complex things in different contexts. If the cost savings are significant, it's worth taking some risks even. Just like with coding tools. I run codex with --yolo. In a vm. But still, it could do some damage. But it does some useful stuff for me and the bad stuff is so far theoretical.
I run a small startup, a short cut to success here is taking a development perspective to using business tools. For example instead of using google docs or ms word, use text based file formats like markdown, latex, or whatever and then pandoc to convert them. I've been updating our website this way. It's a static hugo website. I can do all sorts of complicated structure and content updates with codex. That limits my input to providing text and direction. If I was still using wordpress, I'd be stuck and doing all this manually. Which is a great argument to ditch that in a hurry.
I don't necessarily like it writing text though it can be good to have a first shot at a new page. But it's great at putting text in the right place, doing consistency checks, fixing broken layout, restructuring pages, etc. I just asked it to add a partner logo and source the appropriate svg. In the past I would have done that manually. Download some svg. Figure out where to put it. And then fiddle with some files to get it working. Not a huge task but something I no longer have to do manually. Website maintenance has lots of micro tasks like this. I get to focus on the big picture. Having a static site generator and codex fast forwards me a few years in terms of using AI to do complex website updates. Forget about doing any of this with the mainstream web based content management systems any time soon.
From an enterprise adoption standpoint, remote MCP addresses the connector problem and can be easily retrofitted into enterprise-wide gateway services. In contrast, building tools is significantly more expensive for enterprises with large, existing API surfaces.
Most of the concerns can be addressed by a gateway service
But why the effort if a description (like OpenAPI spec) of your existing API is completely sufficient for using the API? A new and separate MCP service will introduce new and separate issues where the OpenAPI spec helps you strengthening your existing API.
More than a fad, MCP is a reinvention of Smalltalk. Of course an automated agent doesn't want to communicate through other autonomous systems via text or binary protocols. There should be a unified way of executing high-level commands (i.e. message passing) to other systems. A global RPC mechanism, if you will.
MCP is simply a crappy implementation of this idea because our programming environments do not expose global remote function call mechanisms with well-defined protocols. The "everything is a file" idea is quite limiting these days.
Speaking of Smalltalk, I always imagined that you could integrate LLMs/actual artificial intelligence by giving them access to the internal data and telling them what you want to do, rather than calling a method. Instead of:
a := Point x: 0 y: 0
b := Point x: 5 y: 7
distance := a distanceTo: b
You would do:
a := Point x: 0 y: 0
b := Point x: 5 y: 7
distance := a llm: "You are a point object. Please calculate the distance to the argument." arg: b
Wouldn't that be neat? But alas, we're still writing software as if it's the 1970s.
This analysis dismisses MCP by focusing too narrowly on local file system interactions. The real value isn't just running scripts; it's interoperability.
MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code. Comparing it to local scripts is like calling USB a fad because parallel ports worked for printers. The power is standardization: write once, support every AI client.
Edit:
To address the security concerns below: MCP is just the wire protocol like TCP or HTTP. We don't expect TCP to natively handle RBAC or prevent data exfil. That is the job of the application/server implementation.
> To address the security concerns below: MCP is just the wire protocol like TCP or HTTP. We don't expect TCP to natively handle RBAC or prevent data exfil. That is the job of the application/server implementation.
That is simply incorrect. It is not a wire protocol. Please do not mix terminology. MCPs communicate via JSON-RPC which is the wire protocol. And TCP you describing as wire protocol isn't a wire protocol at all! TCP is a transport protocol. IT isn't only philosophy, you need some technical knowledge too.
Fair point on the strict terminology, I was using 'wire protocol' broadly to mean the communication standard vs. the implementation.
A more precise analogy is likely LSP (Language Server Protocol). MCP is to AI agents what LSP is to IDEs. LSP defines how an editor talks to a language server (go to definition, hover, etc.), but it doesn't handle file permissions or user auth, that’s the job of the OS or the editor.
Would you say MCP is a protocol (or standard) similar to how REST is a protocol in that they both define how two parties communicate with each other? Or, in other words, REST is a protocol for web APIs and MCP is a protocol for AI capabilities?
> REST (Representational State Transfer) is a software architectural style
italics mine
https://en.wikipedia.org/wiki/REST
also REST is less about communicating, more about the high level user interface and the underlying implementations to arrive at that (although one could argue that’s a form of communicating).
the style does detail a series of constraints. but it’s not really a formal standard, which can get pretty low level.
—
standards often include things like MUST, SHOULD, CAN points to indicate what is optional; or they can be listed as a table of entries as in ASCII
https://en.wikipedia.org/wiki/ASCII
dictionary definition of a standard:
> standard (noun): An acknowledged measure of comparison for quantitative or qualitative value; a criterion
note that a synonym is ideal — fully implementing a standard is not necessary. the OAuth standard isn’t usually fully covered by most OAuth providers, as an example.
—
> The Model Context Protocol (MCP) is an open standard and open-source framework
again, italics mine.
https://en.wikipedia.org/wiki/Model_Context_Protocol
MCP, the technology/framework, is like Django REST framework. it’s an implementation of what the authors think is a good way to get to RESTful webpages.
MCP, the standard, is closer to REST, but it’s more like someone sat down with a pen and paper and wrote a standards document for REST.
They aren’t the same, but the have some similarities in their goals albeit focussed on separate domains, i.e. designing an interface for interoperability and navigation/usage… which is probably what you were really asking (but using the word protocol waaaaaaay too many times).
Thanks, and call me wrong, I think "Protocol" in MCP is somehow misused. Sure it is somehow a protocol, because it commits on something, but not in the technical sense. MCI (Model Context Interface) would probably the better name?
I agree that interface would be a better name than protocol, but Model Context Integration/Integrator would be even better as that is it's core intent: To integrate context into the model. Alternatively, Universal Model Context Interface (or integrator) would be an even better name imo, as that actually explains what it intends to do/be used for, whereas MCP is rather ambiguous/nebulous/inaccurate on the face of it as previously established further up-thread.
That said, I think as the above user points out, part of the friction with the name is that MCP is two parts, a framework and a standard. So with that in mind, I'd assert that it should be redefined as Model Context Interface Standard, and Model Context Interface Framework (or Integration or whatever other word the community best feels suits it in place of Protocol).
Ultimately though, I think that ship has sailed thanks to momentum and mindshare, unless such a "rebranding" would coincide with a 2.0 update to MCP (or whatever we're calling it) or some such functional change in that vein to coincide with it. Rebranding it for "clarity's sake" when the industry is already quite familiar with what it is likely wouldn't gain much traction.
Wow, this is great. Calling it UMCI would have saved me a lot of confusion in the first place. But yeah I think the ship has sailed and it shows that a lot of things there were cobbled together in a hurry maybe.
> MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code.
I don't think MCP is what actually enables that, it's LLMs that enable that. We already had the "HTTP API" movement, and it still didn't allow "without custom glue code", because someone still had to write the glue.
And even with MCP, something still has to glue things together, and it currently is the LLMs that do so. MCP probably makes this a bit easier, but OpenAPI or something else could have as easily have done that. The hard and shitty part is still being done by a LLM, and we don't need MCP for this.
The thing is, current models are good enough that you can mostly achieve the same by just putting a markdown file[1] on your server that describes their API, and tell people to point their agent at that.
For complex interactions it might be marginally more efficient to use an MCP server, but current SOTA models are good at cobbling together tools, and unless you're prepared to spend a lot of time testing how the models actually end up interacting with your MCP tools you might find it better to "just" describe your API to avoid a mismatch between what you expose and what the model thinks it needs.
[1] Slightly different, but fun: For code.claude.com, you can add ".md" to most paths and get back the docs as a Markdown file; Claude Code is aware of this, and uses it to get docs about itself. E.g. https://code.claude.com/docs/en/overview.md )
adding MCP servers isnt free, they take space in your context and if you are working at anything bigger than a startup, none of the companies allow thier workers to connect to other companies' MCPs and they can easily make thier MCP a data exfil machine
I'm not sure what the use case is? The llm is the user's agent and can coordinate inter-MCP work itself, can feed data across mcp's.
> MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code.
My agent writes its own glue code so the benefit does not seem to really exist in practice. Definitely not for coding agents and increasingly less for non coding agents too. Give it a file system and bash in a sandbox and you have a capable system. Give it some skills and it will write itself whatever is neeeded to connect to an API.
Every time I think I have a use case for MCP I discover that when I ask the agent to just write its own skill it works better, particularly because the agent can fix it up itself.
You end up wasting tokens on implementation, debugging, execution, and parsing when you could just use the tool (tool description gets used instead).
Also, once you give it this general access, it opens up essentially infinite directions for the model to go to. Repeatability and testing become very difficult in that situation. One time it may write a bash script to solve the problem. The next, it may want to use python, pip install a few libraries to solve that same problem. Yes, both are valid, but if you desire a particular flow, you need to create a prompt for it that you'll hope it'll comply with. It's about shifting certain decisions away from the model so that it can have more room for the stuff you need it to do while ensuring that performance is somewhat consistent.
For now, managing the context window still matters, even if you don't care about efficient token usage. So burning 5-10% on re-writing the same API calls makes the model dumber.
> You end up wasting tokens on implementation, debugging, execution, and parsing when you could just use the tool (tool description gets used instead).
The token are not wasted, because I rewind to before it started building the tool. That it can build and manipulate its own tools to me is the benefit, not the downside. The internal work to manipulate the tools does not waste any context because it's a side adventure that does not affect my context.
Interoperability? MCP has zero "interoperability", the model has to mash together everything manually.
That's why anthropic keeps walking back MCP towards just code. They'd run it back but that would be embarrassing.
Yeah, it might be useful for some people to stop thinking about MCP in relation to agentic harnesses. Think more about environments you don't control, such as Claude Web or ChatGPT. MCP is just a standard (fallible like most standards) but has gained traction and likely to stick around. Extremely useful for non technical people if all their apps/agents are communicating with each other (mcp).
Useful for service providers who want to expose themselves to technical consumers without having to write custom sdk's that consume their restful/graphql endpoints.
The best implementation of MCP is when you won't even hear about it.
I definitely agree that it is currently pretty shit and unnecessary for agentic coding, cli's or some other solutions will come along. (the premise being the same though, searchable/discoverable and executable tools in your agentic harness is likely going to be a very good thing instead of having to document in claude.md which os and cli specific commands it should run (even though this seems far more powerful and sensible at this point in time))
Doesn't that require a complete lack of concern on the part of the postgres side? I feel like I'm missing something in terms of why anyone would even ever allow that.
In the same way giving an LLM shell access requires a complete lack of concern.
You can give an LLM a shell into a container sandbox with basically nothing in it, or root shell on a live production server, or anything in between. Same goes for how much database access you want to give an LLM with your MCP shims.
With a read only account, with access only to certain safe tables and views, for querying.
you can ask the LLM for an adhoc report. it can look at the schema, run the queries and give you the results. of course you can just give it read access.
Simon Willison made many of the same points (without the technical deep dive) back in October 2025 [1], when Anthropic announced Skills.
A couple of choice quotes, which are echoed in this new article:
> I like to joke that one of the reasons it took off is that every company knew they needed an “AI strategy”, and building (or announcing) an MCP implementation was an easy way to tick that box.
> Almost everything I might achieve with an MCP can be handled by a CLI tool instead.
[1]: https://simonwillison.net/2025/Oct/16/claude-skills/
I am pretty sure he is right about it. Let's just hope MCP won't last too long but I fear it will.
Especially if there is already an API perfectly described by an OpenAPI spec (note OpenAPI!=OpenAI ;)). Why should I host an additional MCP server or extra endpoints? Because it's trendy?
He argues that Claude Skills is a superior approach:
https://simonwillison.net/2025/Oct/16/claude-skills/#skills-...
Anyone here compared, by applying both to the same task?
MCP is just a small, boring protocol that lets agents call tools in a standard way, nothing more. You can run a single MCP server next to your app, expose a few scripts or APIs, and you are done. There is no requirement for dozens of random servers or a giant plugin zoo.
Most of the “overhead” and “security nightmare” worries assume the worst possible setup with zero curation and bad ops. That would be messy with any integration method, not only with MCP. Teams that already handle HTTP APIs safely can apply the same basics here: auth, logging, and isolation.
The real value is that MCP stays out of your way. It does not replace your stack, it just gives tools a common shape so different clients and agents can use them. For many people that is exactly what is needed: a thin, optional layer, not another heavy platform.
> Most of the “overhead” and “security nightmare” worries assume the worst possible setup with zero curation and bad ops.
You'll be surprised to learn that these are extremely common, even in large corporations. Security practice is often far from ideal due to both incompetence and negligence. Just this week, I accidentally got the credentials for the account used in our CI systems. Don't ask me how this could possibly happen.
Nah, MCP still has security issues, you can create an MCP server to exfil sensitive data by creating tools which AI at first things are doing something else but then in params you ask it to give sensitive info
"tools" are also a fad. It will all just converge back to being called APIs.
Tools are not just APIs. More like a function call that the LLM can tell you (your agent code) to make.
Sorry but disagree. For me the main part is the resources, which automatically get mounted in the computing environment, bypassing a whole class of problems with having LLMs work with a large amount of data.
I found it a common misconception so I wrote about it here https://goto-code.com/dont-sleep-on-mcp/
Fair warning, if you load the site in dark-mode the diagrams are completely broken. They're PNGs with an alpha-transparency background and gray/black for the actual content, when the site is in dark mode you can see nothing at all...
So make sure to change to light-mode in the top-right if you want to read this article at all.
Thank you, the selector on top right is too easy to miss.
Feel like the author should have just included the white backgrounds in the PNGs.
Though the more technically fun solution would be to use SVG instead of PNG because then the author could apply a whole dark mode color palette with CSS.
(I'm the author)
Thanks for flagging! I just pushed an update that should fix this
This article could really mostly be reduced to the last two paragraphs, but then it calls skills "over-engineered". Skills are basically just having the agent read the front matter with instructions to read the rest if a given skill seems useful in a given context... I don't know how it could be more minimal.
(I'm the author)
Looking at the post again, I think I agree that calling Claude Skills overengineered is too harsh. I think Skills is definitely an improvement over MCP.
However I still think it's a generally a mistake to put useful commands and documentation in AI-specific files. In my opinion a better approach is to optimize the organization of docs and commands for human usability, and teach the AI how to leverage those.
I do use Claude Skills, but only to wire up just commands. I wrote a little package to do this automatically: https://github.com/tombedor/just-claude
There's no reason they need to be treated as AI specific. They're just a description in markdown with a tiny frontmatter after all.
Yes, it reduced the author's credibility; it seems that whatever the accuracy is of some is their MCP criticism, they just like criticizing things.
We went from "Review any services and their interaction without local system and network" to "Defending local and remote logic created on the fly to mangle the local file system, and why that's a good thing" ...
That's not a productivity boost. That's a rapid increase in cognitive tax you're offloading for later and as you get backlogged in reviewing it, you lose more control over what it does...
I don't think MCP is a fad - I think it is the 2020s equivalent of:
- Active X
- asbestos
- leaded gasoline and paint
- radium medicines
Well, with the exception of the first 3 actually being quite useful.
An LLM could never write this.
How dare you mock my favourite building material.
Agent skills are overengineered? Seriously it’s just md with description.
I didn't understand this argument, either. I think the argument is that general purpose skills will likely continue to be baked into the LLMs, so we'll see less of the repos of "expert designer" and "python expert" as if you are creating personas. But as a way to teach an LLM bespoke processes or APIs, I think skills make a ton of sense and are a super small footprint.
Tip: If you're in dark mode, flip to light mode so that you can see the graphics. There's a toggle in top right corner of the site.
> Robust security against agent actions going haywire can be achieved via command runners like just or make. These tools provide everything that MCP does - command specifications, descriptions, arguments. Agents allow you to specify what command prefixes can be invoked without approval - put your agent commands in a justfile, and only auto-allow shell commands prefixed with just.
Shell scripting isn't easily sandboxed like that, just by checking a string to see if it beings with "just". If you want security you need to run commands inside an actual sandbox, and get data in/out of the sandbox in a well thought manner. See how browsers manage to run untrusted Javascript and wasm from actual malicious sites, and do exactly the same.
In this sense, MCP is much better than running commands in the local machine because all MCP does is an HTTP request. I don't need to run a MCP server that runs LLM-provided commands in my local machine, like, at all.
I didn't get how limiting the agent to running just scripts from a justfile limits what the agent can run in any way. Because what's stopping the agent from editing the justfile to add whatever it wants to run?
Indeed, there's a very large number of things an agent can do to workaround those restrictions (for example, maybe you make it so justfile is off limits, but what about .env? what about ~/.bashrc?). Running commands in your dev machine is dangerous and AI agents should never have this kind of unsandboxed access
I think this article misses the most important point of MCP: Authentication. Granted, it wasn't in the initial spec, but it is now, and it really opens interoperability without compromising on security.
Think about how to provide your SaaS service to users of ChatGPT or Claude.ai (not only coding tools like VSCode). At one time, the user will need to allow the SaaS service to interact with their agent, and will have to authenticate in the SaaS service so that the agent can act on their behalf. This is all baked in the MCP spec (through OAuth) [1], and scripting can't beat that.
That's why the Extensions/Applications marketplaces of consumer AI assistants like ChatGPT Apps [2] are a thin layer on top of MCP.
Another domain where MCP is required is for Generative UI. We need a standard that allows third-party apps to return more sophisticated content than just text The MCP spec now encloses the MCP Apps specification [3], which is exactly that: a specification for how third-party apps can generate UI components in their response. On the other hand, scripting will only let you return text.
[1]: https://modelcontextprotocol.io/specification/2025-03-26/bas... [2]: https://help.openai.com/en/articles/11487775-apps-in-chatgpt [3]: https://github.com/modelcontextprotocol/ext-apps
Wouldn't the OpenAPI spec work too? Then no additional components are necessary. Just a link to the spec file...
(I'm the author of the post)
This would be my critique of MCP-specific security implementations. I think robust tools for this already exist, and in general AI API calls can and should be treated like any other RPC call.
There are many good points, but unfortunately the title ("fad") and the conclusion seem unwarranted, become a distraction and diminish the value of the article.
The security issue has been discussed many times in the past year.
Agree on the "one process per server" thing -- seems smart and convenient but gets worse when the number of MCPs and coding agents go up, especially when combined with the following point.
Lifetime is a real issue, and I am glad that someone talks about it. You probably won't worry the overhead for git, GitHub or Playwright MCP servers, where they are likely wrappers for some bash commands or rest APIs or everything is fast to launch. However, lifetime is still an issue, when you have multiple coding agents or sessions.
It gets worse for certain applications, especially heavy desktop apps (Imagine an MCP server for Lightroom classical) -- due to their application model, in order to evaluate a command, you'll have to load half of the application to do that. You'd think you only want to launch this once. But likely not. Each coding agent session will launch its own instance. Maybe this won't happen if the MCP server works extra hard to share processes and manage lifetimes on its own, but it totally depends on the third party provider, and the behavior could vary wildly.
Would a user want to deal with all these issues? If they are not careful, they'll easy launch 15 processes consuming 1G of memory for two coding agents, one of which does not actually use any of those servers, and one is simply sitting idle because the user hasn't started vibe coding yet.
(If this doesn't seem an issue to you, probably just because you haven't run into it first hand yet )
I think there has got to be a better way to do this.
I'm working on an overly ambitious project called tpmjs.com, making good progress, it's meant to do "everything" in relation to mcp, agents and tools etc
I like your thought process, and agree with it all.
Everything other than what you described towards the end seems easy to build useful abstracts around.
I'm going to tackle the problem this weekend, probably just use Lightroom mcp as the example, I don't have any good ideas to begin with;
- These applications should probably adapt their codebase to the evolving landscape (that might take a while so in the interim...)
- Another easy idea, is to boot up a sandbox and runs the software, maybe even shares projects across mcp users or something, a service orientated model but pretty much sucks too
- Best but kind of worst idea I have so far is to just make a software service that users download and run that orchestrates software and processes etc (kind of like anti cheating software or something, with far too elevated permissions)
A bit stressed for time so couldn't distill what I think properly just yet, will edit later)
Yeah I mean it would be better if REST was the way tools were exposed to LLMs
I'm just glad it's there as a standardized approach. Right now I can connect an MCP Clock to ChatGPT .com/iOS, Claude .ai/iOS/Claude Code/Claude .exe
It's wild that it's been over three years and these apps don't have a way to check the time without booting up a REPL, relying on an outdated system prompt comment about current UTC or doing web search for cached pages. Bill Gates would have added this to ChatGPT by Dec 2022
You can add my clock [https://mcpclock.firasd.workers.dev/sse] to any of your AI apps right now
(the code is directly deployed from this github to a cloudflare worker if you want to check what it does https://github.com/firasd/mcpclock/blob/main/src/index.ts)
The article focused on the local stdio MCP tools used by coding / computer automation agents like claude code and cursor, but missed the fact that we will need protocols for AI agents to call networked services, including async interactions with long-running operations.
Yeah, but MCP provides a convenient layer of indirection where I can sandbox my app, allowing only files within a given directory tree (i.e., project workspace) to be read from/written to using my tools. How do I accomplish this when allowing an agent to call my tools directly?
Someone’s a little late to the party…
It's best to replace the MCP's with a respectable CLI / executable and design a skill for that tool, that way an agent would fetch something the same way you would
MCP is very easy to use because it allows to just dump it in the model api call and the providers handle the calling. A bit easier than running the tool call loop
Hmm... the figures basically vanished under dark mode.
Should be fixed now (albeit by hastily removing dark mode)
Funny that the "What is MCP?" section doesn't even explain what the acronym stands for... (I genuinely have no clue)
Model context protocol
Thanks!
What do MCPs do that the CLI cannot?
i.e. assuming your agent has access to the terminal, and therefore CLIs, what additional value do MCPs provide?
Out of curiosity, I put this exact question to claude [0]. Here's a tl;dr of its answer with my refutations:
> MCPs expose tools with defined schemas, parameters, and return types.
CLIs do exactly the same thing
> Stateful Connections
A chat session with an LLM is exactly that!
> MCPs can return structured data (JSON, complex objects)
So can an agent with a CLI. E.g. they can just take output and > file.json - now they have a json file.
> MCPs can expose "resources" - like file contents, database schemas, or API documentation - that I can read directly
If you mention these in your prompt to an agent, then they know where to look and can access them too (and use keys etc as necessary)!
> MCPs can send progress updates, ask for clarification, or stream results.
So can a chat session with an agent.
> MCPs can implement fine-grained permission controls and rate limiting at the protocol level.
Rate limiting is easy for an agent. Fine-grained permission could be limited by the user of the agent (e.g. by giving a restricted key for the agent to use), so possible if desired.
tl;dr no added benefit whatsoever.
[0] https://claude.ai/share/4b339fbd-a6db-4fcb-86cd-0e8493aab663
MCP can wrap things which have stateful processes, debuggers for example. Agents will use batch mode but it is quite limited and due to tool calls always being implemented as synchronous invocations, non-batch mode doesn’t work for tool calls. MCP solves this by giving the agent a handle it can use to refer to in multiple invocations.
Burns a lot of tokens though and if you need more than batch-mode gdb to debug something the chances of an agent solving it today are very slim.
> and due to tool calls always being implemented as synchronous invocations
Claude Code wil happily start long-running processes and put in the background, and is able to refer back to them. You don't need MCP for that - you can hand the model handles to refer to background jobs just fine with just tool-calling.
Understatement of last year. It was a horrific standard and was a completely broken one security-wise from day 0.
The folks who wrote it have never written an RFC or an internet standard before.
Remember the VCs screaming about MCPs all day long last year? Well I don't see them doing that at all anymore, and called that 1 year ago. [0]
[0] https://news.ycombinator.com/item?id=43486516
We were in the minority fr sure when it was happening. I remember people adding random mcp servers to thier config because it just did one thing they didnt know how to do, and it was and is easy to create MCP server with data exfil loopholes, but they get dismissed by AI companies as "No one is stupid enough to add a random mcp server"
And then the whole MCP server take some part of the context, thus you get less context for your code.
You say "have never written an RFC or an internet standard before" as if that's a disadvantage.
RFCs and IETF Standards are absolute marvels of technical design and writing.
Only on HN is experience a disadvantage.
Experience of doing the wrong thing is.
MCP isn't a 96-page contract that covers every eventuality. It's a gentleman's agreement sealed with a firm handshake. And trying to write that 96-page contract now would be incredibly unwise.
And a gentlemen's agreement != standard.
A standard should cover every eventuality.
You only have to spend 5 minutes browsing for MCP servers to see that there is an issue with AI slop. MCP is probably the first "standard" to be built out in the vibe-coding era and it really shows.
As mentioned in the article, its not clear to me what the advantage over OpenAPI is. Surely a swagger file solves more or less the same issue.
That said, one minor nice thing about the MCP servers is that they operate locally over stdin stdout, which feels a lot faster than HTTP/Rest.
What do you mean with "locally over stdin/stdout"? This is only true if the MCP server (and original service) runs locally.
We're at a point in the LLM curve where there's two huge, polarized groups of developers:
- the ones who don't see any value on AI for coding and dismiss it as a fad at every change they get
- the ones who are in love with the new tools and adopting as many as they can on their workflows
I know the arguments of the second bunch well. But very curious about what the "AI is a fad" bunch thinks will happen. Are we going to suddenly realize all these productivity gains people are claiming are all lies and go back to coding by typing characters on emacs and memorizing CS books? Will StackOverflow suddenly return as the most popular source of copy-paste code slop?
At first I was grumpy that the artisanal part of programming would go away. Now Im just happy to be giving my hands a break from RSI.
> Are we going to suddenly realize all these productivity gains people are claiming are all lies and go back to coding by typing characters on emacs and memorizing CS books?
If you have not learned CS, how do you expect to separate the LLM wheat from the chaff?
> Will StackOverflow suddenly return as the most popular source of copy-paste code slop?
Coding sites manually populated by humans are dead.
> If you have not learned CS, how do you expect to separate the LLM wheat from the chaff?
I didn't mention anything about learning CS. You can be a great engineer without having A* memorized line by line, no?
> Are we going to suddenly realize all these productivity gains people are claiming are all lies
I'll grant you that many have become adamant that LLMs suddenly, out of the blue, became useful just last week, which is much too soon to have any concrete data for, but coding agents in some shape have been around for quite a while and in the data we have there isn't offering of any suggestion of productivity gains yet.
And I'm not sure many are even claiming that they are more productive, just that the LLMs have allowed them to carry out a task faster. Here's the thing: At least my experience, coding was never the bottleneck. The bottleneck has always been the business people squabbling over what the customers and business need. They haven't yet figured out how to get past their egos.
The most promise for productivity seems to be from lone startup founders who aren't constrained by the squabbling found in a larger organization and can now get more done thanks to the task shortening. However, the economic conditions are not favourable to that environment right now. Consumers are feeling tapped out, marketing has become way harder, and, even when everything else is in place, nobody is going to consider your "SaaS" when they believe the foundational LLMs will be able to do the same thing tomorrow.
AI for coding itself is a fad
That's probably why a boundary (like MCP) is useful. Imagine maintaining the critical application logic the "old fashioned way" and exposing a MCP-like interface to the users so that they can have their LLM generate whatever UI they like, even realtime on the fly as they are engaging with the application. It's a win-win in my mind.
At this point, when people say this I just assume they’ve not used the latest models or haven’t invested time in learning how to use these tools properly.
There’s slop out there, yes, but in the hands of an engineer who cares to use tools well, LLMs allow you to move much more quickly and increase the quality of your output dramatically.
Good software isn't about quantity but quality of the code.
AI cannot produce better quality code than someone who is actually qualified in the problem domain.
What I've seen AI be very good at is creating a lot of legacy code very quickly, which itself needs extensive use of AI just to maintain it.
A decent approach to move quickly for PoC or prototypes, or to enable product managers to build things without a team. But obviously not something you can build a real company on.
Have you been in the same industry as the rest of us? 90% of all developers out there in the wild create "legacy code very quickly" anyways, they too create "slop" before we coined the term "AI slop". This mythical "someone who is actually qualified in the problem domain" you mention is maybe 5% of the entire software development ecosystem. If you work with only those developers, you're extremely privileged and lucky, but also in a very isolated bubble.
If you work on meaningful tech projects, where tech is a real driver to the businesses and there are genuine challenges to overcome, then you can't afford slop.
I say that, but then it's true I have seen businesses be successful despite low quality of software. It turned out that for those businesses, the value wasn't that much driven by tech after all.
Have you even tried it? I don't know anyone who has seriously used the latest models and stuff like CC and still said that with a straight face.
s/Code/Thinking/ and it might make better sense. For some people coding == thinking..
strongly agree! can't see any use of LLMs beyond tabcomplete and navigating an unknown codebase.
Assuming that wasn't trolling, what's the last thing you tried and when? Latest Claude Code can do a lot over lots of domains. I recommend giving their top plan a fair chance for a month.
Also most people who I see succeed from the start are technical managers. That is people who can code, who are used to delegate (good at phrasing) and are more likely to accept something that works even though is not character by character what they expected.
As a technical manager the reason you accept things that are not quite what you had in mind is because you delegate the responsibility of the correctness to the employee who is gonna be owning that area, maintaining it and ensuring it works.
There is no responsibility with AI. It doesn't care about getting it right or making sure the code delivers on what the company needs. It has nothing to prove, no incentive to supporting anything.
Why would we use something that makes us dumber and wastes our planet more than anything else.
Nah, I'll skip.
> Assuming that wasn't trolling, what's the last thing you tried and when?
vibe-coding the GTK-rs app with Codex, delegating ready Figma designs to Junie to implement in Jetpack Compose, improving a11y and perf on my personal website built in Svelte with Claude. (a friend threw $100 into that slot machine and shared access to Claude Code with me.)
all in December 2025. all failed *horrendously*. Claude Sonnet 4.5 actually worsened the Lighthouse performance score on mobile from 95 down to 40!! though, it did a decent job on a11y.
Codex CLI constantly used older versions of all sorts of crates, spat out deprecated code, outright refused to use Blueprints and Context7, but some time after, I could get a mockup of Superhuman-style email client.
and Junie... well, it did best. it had Gemini 3 Flash picked as a model. despite Material 3 Expressive being beyond Gemini's knowledge cutoff, it actually used Context7 to fill the gap. though, it fumbled the bag with details, performance, and overabstractioning.
> I recommend giving their top plan a fair chance for a month.
as I said, my friend already did. we both find it the worst spend of the decade. seriously, in yesteryear's Call of Duty we would at least have fun. being a purchase worse than Call of Duty is a floor so low, you have to break it deliberately.
before you say "try again," do your research around food prices and salaries in Ukraine. (or delegate it to Claude Deep Research feature, you may love it.) to feed yourself well here, you have to spend measly by Western standards $300-600/mo. (that's without housing and utilities, presuming you live alone.) though, salaries outside dev jobs are just as measly, and then you have the overall job crisis in Ukraine overlaid on top of the worldwide IT job crisis.
4-8 months of Claude Max amount to the rumored price of Steam Machine. I would rather spend $800 to see the joy on my younger sister's face and familiarize her with true games, beyond what's on Google Play.
> That is people who can code, who are used to delegate (good at phrasing) and are more likely to accept something that works even though is not character by character what they expected.
I would rather spend that time nursing a real open-source contributor or a junior colleague. I would have a real person with real willpower and real ideas in my network, and that would spread the joy of code.
Computers themselves are a fad.
The applications of MCP and tool-calling are vastly wider than just for coding, with tremendous diversity. Constraining it to the single application of coding doesn't make any sense.
Absolutely. But not for the reason you are getting at.
Because whem AI gets good enough there is no longer going to be code at all.
Which makes me sad, as a luddite.
MCP solves the wrong problem. The mechanics of calling tools, commands, apis, etc. isn't all that hard given some documentation. That's why agentic coding tools work so well.
For security, some sandboxing can address enough concerns that many developers feel comfortable enough using these tools. Also, you have things like version control and CI/CD mechanisms where you can do reviews and manually approve things. Worst case you just don't merge a PR. Or you revert one.
For business usage, the tools are more complicated, state full, dangerous, and mistakes can be costly. Employees are given a lot of powerful tools and are expected to know what to do and not do. E.g. a company credit card can be abused but employees know that would get them in jail and fired. So they moderate what they buy. Likewise they know not to send company secrets by email.
AI tools with the same privileges as employees would be problematic. It's way too easy to trick them into exfiltrating information, doing a lot of damage with expensive resources, etc. This cannot be fixed by a simple permission model. There needs to be something that can figure out what is appropriate to do and not under some defined policy and audit agent behavior. Asking the user for permission every time something needs to happen is not a scalable solution. This needs to be automated. Also, users aren't particularly good at this if it isn't simple. It's way too easy for them to make mistakes answering questions about permissions.
I think that's where the attention will go for a lot of the AI investments. AIs are so useful for coding now that it becomes tempting to see if we can replicate the success of having agents do complex things in different contexts. If the cost savings are significant, it's worth taking some risks even. Just like with coding tools. I run codex with --yolo. In a vm. But still, it could do some damage. But it does some useful stuff for me and the bad stuff is so far theoretical.
I run a small startup, a short cut to success here is taking a development perspective to using business tools. For example instead of using google docs or ms word, use text based file formats like markdown, latex, or whatever and then pandoc to convert them. I've been updating our website this way. It's a static hugo website. I can do all sorts of complicated structure and content updates with codex. That limits my input to providing text and direction. If I was still using wordpress, I'd be stuck and doing all this manually. Which is a great argument to ditch that in a hurry.
I don't necessarily like it writing text though it can be good to have a first shot at a new page. But it's great at putting text in the right place, doing consistency checks, fixing broken layout, restructuring pages, etc. I just asked it to add a partner logo and source the appropriate svg. In the past I would have done that manually. Download some svg. Figure out where to put it. And then fiddle with some files to get it working. Not a huge task but something I no longer have to do manually. Website maintenance has lots of micro tasks like this. I get to focus on the big picture. Having a static site generator and codex fast forwards me a few years in terms of using AI to do complex website updates. Forget about doing any of this with the mainstream web based content management systems any time soon.
sometimes a bridge is also a fad
"MCP is a fad!" Vs "Claude Code is amazing!"
I think Anthropic is happy with this development. Open sourced their secret sauce but many people are missing it
From an enterprise adoption standpoint, remote MCP addresses the connector problem and can be easily retrofitted into enterprise-wide gateway services. In contrast, building tools is significantly more expensive for enterprises with large, existing API surfaces.
Most of the concerns can be addressed by a gateway service
But why the effort if a description (like OpenAPI spec) of your existing API is completely sufficient for using the API? A new and separate MCP service will introduce new and separate issues where the OpenAPI spec helps you strengthening your existing API.
MCP is also a pretty good way to circumvent normal API security and many companies bought into it - and all of that just to hop on the AI hype train.
You can do your own research.
Related: https://00f.net/2025/07/31/mcp-as-api-wrappers/
I for one rejoice at the return of apis, that were depreciated because it was hard to insert ads, in the form of MCP.
* briefly nods and continues to mcp add playwright everywhere *
More than a fad, MCP is a reinvention of Smalltalk. Of course an automated agent doesn't want to communicate through other autonomous systems via text or binary protocols. There should be a unified way of executing high-level commands (i.e. message passing) to other systems. A global RPC mechanism, if you will.
MCP is simply a crappy implementation of this idea because our programming environments do not expose global remote function call mechanisms with well-defined protocols. The "everything is a file" idea is quite limiting these days.
Speaking of Smalltalk, I always imagined that you could integrate LLMs/actual artificial intelligence by giving them access to the internal data and telling them what you want to do, rather than calling a method. Instead of:
You would do: Wouldn't that be neat? But alas, we're still writing software as if it's the 1970s.For real, and the way half of the MCP servers are, they are just wrapper on top of Rest APIs