Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP vs. API Explained

norahsakal.com

Post reply on HN
Print view View original

51–60 of 119 posts

Re: MCP vs. API Explained

#51

Post by frabjoused »

rsp1984 wrote: post #16

To be honest I don't understand why this is needed. All the leading AI models can already write code that interfaces perfectly with well-known APIs, and for the niche-APIs I can supply the docs of that API and the model will understand. So all that's needed are API docs. Or what am I missing?

The success rate of this is impractically low. APIs are dirty, inconsistent things. Real-world connection to obscure APIs is a matter of hard sleuthing. Docs are wrong, endpoints are broken, auth is a nightmare. These APIs need to be massaged in advance and given a sanity-wrapper if you want any semblance of reliable success when a model calls them.

Re: MCP vs. API Explained

#52

Post by frabjoused »

saurik wrote: post #40
nsonha wrote: post #22

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?

This is very naive. How many different APIs have you authenticated with and connected to? Just the big ones? What happens when the docs are wrong or incomplete?

Re: MCP vs. API Explained

#53

Post by saurik »

outofpaper wrote: post #30
saurik wrote: post #21

Earlier quoted context omitted.

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…

No, an API is the closest term, as calling MCP, which is a simple protocol, an SDK is literally wrong. A protocol is not a software development kit.

I am not even the person who said "I wouldn't call it another form of API"... can you maybe just stick to the concrete and explain how this is different from SOAP/WSDL or OpenAPI/Swaggar? I honestly don't even know what short term either I or you would now use for any of them, but I feel confident that the overall premise described by this article doesn't differentiate: they offer a standardized connector to various tools and data sources behind otherwise different APIs, even offering--through a registry such as UDDI--dynamic discovery of these resources. The only not-really-a-difference I feel is that we are explicitly describing wrapping the other APIs into this protocol... but like, that's what you'd of course have to do or expose an existing API via SOAP (which is also a capital-P-stands-for-Protocol).

Re: MCP vs. API Explained

#54

Post by nostrebored »

frabjoused wrote: post #51
rsp1984 wrote: post #16

To be honest I don't understand why this is needed. All the leading AI models can already write code that interfaces perfectly with well-known APIs, and for the niche-APIs I can supply the docs of that API and the model will understand. So all that's needed are API docs. Or what am I missing?

The success rate of this is impractically low. APIs are dirty, inconsistent things. Real-world connection to obscure APIs is a matter of hard sleuthing. Docs are wrong, endpoints are broken, auth is a nightmare. These APIs need to be massaged in advance and given a sanity-wrapper if you want any semblance of reliable success when a model calls them.

Wouldn’t you just do that with an SDK? Why the extra layer of complexity with MCP?

Re: MCP vs. API Explained

#55

Post by frabjoused »

nostrebored wrote: post #54
frabjoused wrote: post #51

Earlier quoted context omitted.

The success rate of this is impractically low. APIs are dirty, inconsistent things. Real-world connection to obscure APIs is a matter of hard sleuthing. Docs are wrong, endpoints are broken, auth is a nightmare. These APIs need to be massaged in advance and given a sanity-wrapper if you want any semblance of reliable success when a model calls them.

Wouldn’t you just do that with an SDK? Why the extra layer of complexity with MCP?

Not all http based APIs have an SDK. It’s wildly inconsistent. And when you ask the llm to do something new, does it download the SDK on the fly?

Re: MCP vs. API Explained

#56

Post by nsonha »

saurik wrote: post #50
nsonha wrote: post #48

Earlier quoted context omitted.

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?

I don't understand your response as it feels like it is also my point, and something I would say to you? :( If the LLM cannot do basic tasks such as this, what are you going to do? Keep throwing more "tools" at it and hope to start building stuff on top of it? People are trying to get these things to do complex multi-step reasoning tasks, including making changes to their codebase (?!), automating behaviors as "agent…

> Keep throwing more "tools" at it and hope to start building stuff on top of it

Yes and it's working? People ARE CURRENTLY building things.

They are NOT currently whinning that LLM is not smart enough so they must sit and wait for the next model to be able to code any problem, (again RELIABLY) on demand.

> People are trying to get these things to do complex multi-step reasoning tasks, including making changes to their codebase (?!), automating behaviors as "agents" that need to predictably and secure function...

You understand that all these are powered by tools calling underneath? The planning and orchestration of tasks follows a structure, to be fed into tools. This is why a plain model cannot do shit, people have to make products with the right tools on top to make a llm behave the way they want, and not just chit chat endlessly.

The abitrary execution approach, if it ever works, is by building tools and MCP servers for code execution. Because obviously it's not the LLM server who executes code.

You clearly have never thought about how to actually build any of these things.

> ...writing API boilerplate

Tool/function calling can be anything, it's you who decided that you can only use it for API boilerplate. Does the word "function" always mean boilerplate in progranming?

Re: MCP vs. API Explained

#57

Post by jes5199 »

saurik wrote: post #13

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…

MCP tends to be much simpler, less powerful than an API that you’d actually try to develop against. The LLMs need the most simplified access patterns possible

Re: MCP vs. API Explained

#58

Post by emrah »

Every API is different/custom whereas MCP is supposed to be universal. Is that it?

Ok but why would every app and website implement this new protocol for the benefit of LLMs/agents?

Re: MCP vs. API Explained

#59

Post by norsak »

redm wrote: post #3

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…

Author here, good point! I should have mentioned that MCP was created by Anthropic but is seeing wider adoption.

Appreciate the feedback - brb I'll update the post to include this!

Re: MCP vs. API Explained

#60

Post by crabmusket »

SamBam wrote: post #41
1116574 wrote: post #7

The article has the same usb-c photo three times, but doesn't actually explain what it is, or how it works.

Not only that, but the whole section on "Consider these scenarios" simply described the same thing as an API each time, but added words like "smoothly" and "richer" to make it sound different. I honestly think most of the article was written by an LLM.

The structure seems very LLM-ish. And the details are blurry:

> Two-way communication: MCP supports persistent, real-time two-way communication - similar to WebSockets. The AI model can both retrieve information and trigger actions dynamically".

This is not what two-way communication means.

Post reply on HN