41–50 of 119 posts
The article has the same usb-c photo three times, but doesn't actually explain what it is, or how it works.
I honestly think most of the article was written by an LLM.
What the article doesn't say (well, there's a lot it doesn't say) is that this protocol was created by Anthropic but is being adopted more widely. MCP reminds me of a new platform opportunity akin to the Apple App Store. It's rapidly adopted, with offerings from GitHub, Stripe, Slack, Google Maps, AirTable, etc. Many more non-official integrations are already out there. I expect this will only gain adoption over the…
But with MCP there's not a whole lot of information out there for LLMs to digest and so perhaps for that reason the article is not particularly insightful.
Thank you HN for bringing the insights!
MCP strikes me as roughly equivalent to HTML. Headline features like dynamic “tool” discovery (and more!) are solved well with HTML. MCP is probably easier for clients to implement but suffers from poor standardization, immaturity and non-human readability. It clearly scratches an itch but I think it’s a local-minimum that requires a tremendous amount of work to implement.
MCP is not that hard to understand why does it keep getting the wackiest comparison?
, etc. and “tools” are , and s. Instead of separating the two (like in MCP) - it’s all included in the same document.
I’ve used MCP quite a bit but perhaps I’m misunderstanding something? Happy to hear why you think it’s “wacky”.
It's much simpler: MCP allows tools to be added at runtime instead of design-time. That's it. And because this can happen at runtime, the user (NOT the developer) can add arbitrary functionality to the LLM application (while the application is running — hence, runtime). One could make the argument that LLM applications with MCP support are conceptually similar to browsers — both let users connect to arbitrary MCP/HTT…
MCP standardizes how LLMs can call tools at runtime, and how tools can call LLMs at runtime. It's great!
1) Ok, so you are reinventing SOAP or WSDL or whatever... did that ever go well? How and why is this different from every prior attempt to create the one true API layer? 2) Is this meaningfully different from just having every API provide a JavaScript SDK to access it, and then having the model write code? That's how humans solve this stuff. 3) If the AI is actually as smart at doing tasks like writing clients for AP…
Question three is what hits the nail on the head about how this “AI revolution” isn’t as robust as often claimed. If it was truly intelligent it could reason about things like API specifications without any precursors or shared structure, but it can’t. Are LLMs powerful? Yes. Is current “AI” simply a re-brand of machine learning? IMO, also yes
I say this out loud so someone can correct me if I’m mistaken!
Earlier quoted context omitted.
Question three is what hits the nail on the head about how this “AI revolution” isn’t as robust as often claimed. If it was truly intelligent it could reason about things like API specifications without any precursors or shared structure, but it can’t. Are LLMs powerful? Yes. Is current “AI” simply a re-brand of machine learning? IMO, also yes
My impression, and perhaps this is wildly off, is that MCP could be useful to whitelist safe usage of tools by LLMs. I say this out loud so someone can correct me if I’m mistaken!
Earlier quoted context omitted.
I wouldn't call it another form of API. It's more like an SDK. If you were accessing a REST API from Android, iOS, Windows, Mac, Firefox, they'd be mostly the same. But an SDK for Android and an SDK for iOS has been built for the platform. Often the SDK encapsulates the official API. That's a direct answer for (2) too - instead of writing a JS SDK or Swift SDK or whatever, it's an AI SDK and shared across Claude, Ope…
I didn't have a good term so I went with "API layer" (not merely "API"), but, to try to clarify... that's what you also get with SOAP/WSDL or any of the other numerous attempts over the years to build an API "layer" thing: you can use the one universal SDK you have, plus only the schema / IDL, to use the API. Every time people try to describe MCP it just sounds like yet another API description language when we alread…
{"action": "create_directory", "value": "foobar/assets/"} is 15 tokens whereas create_directory("foobar/assets/") is 7 tokens. It's not the exact format, but you get the idea.
It's not just about cost, higher tokens also result in lower performance. It's as hard for the LLM to read this as it is for you to read it.
I did some experiments with protocols last year. YAML was the most efficient one by a large margin, and yet it often made mistakes. Half the output layer code is dedicated to fixing common mistakes in formatting, like when it forgets to put in a dash or merges one parameter with another. We had 2/3 of the input prompt dedicated to explaining the spec and giving examples. It's definitely not trivial.
MCP is pre-trained into the models, no need for all this.
The work we had it on did not need a good model. We had to use a more expensive model and most open source/self-trained ones didn't do the trick. We ended up taking a 3x more expensive model. Also don't look at it as LLMs being smart enough to do it; we also want something for the dumb & cheap micro LLMs as well, and micro LLMs will likely be doing agentic work.
It's also as likely to make mistakes as a human - LLMs didn't output JSON until mid 2024. Gemini was one of the first to officially feature JSON output and it was still randomly breaking by Sept 2024 with JSON arrays, even when giving the API a properly detailed spec to respond in.
They can improve it, but they have to train it on something and they might as well make something up that's more efficient. OpenAI might do one too. Even with images we see newer protocols like HEIC, WEBP when PNG works fine. I expect MCP will live because it's particularly suited to this use case.
Earlier quoted context omitted.
Sorry but I'm extremelly annoyed with this idiotic take that many people seem to have. Is it that easy to prompt AI to write code and call an API predictably?
This is like the simplest task you can give a software developer, as it is nigh-unto merely a document "translation" task, without much real thought required. If an LLM is failing to do this task, why do we hope whatever chain of reasoning it is about to embark on would work?
Also > ...if an LLM is failing to do this task...
It CURRENTLY fails to do so, PREDITABLY and securely. What are you gonna do about that? Keep throwing more data into it and hope to start building stuff on top, one day?
Earlier quoted context omitted.
This is like the simplest task you can give a software developer, as it is nigh-unto merely a document "translation" task, without much real thought required. If an LLM is failing to do this task, why do we hope whatever chain of reasoning it is about to embark on would work?
https://news.ycombinator.com/item?id=43304457 Also > ...if an LLM is failing to do this task... It CURRENTLY fails to do so, PREDITABLY and securely. What are you gonna do about that? Keep throwing more data into it and hope to start building stuff on top, one day?