81–90 of 129 posts
Earlier quoted context omitted.
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.
A standard should cover every eventuality.
Earlier quoted context omitted.
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 ch…
Nah, I'll skip.
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. Lif…
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)
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 standardi…
> 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 a…
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.
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…
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…
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.
Earlier quoted context omitted.
> 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 a…
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?
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).
Most of the concerns can be addressed by a gateway service
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…
"tools" are also a fad. It will all just converge back to being called APIs.
Earlier quoted context omitted.
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 prett…