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

101–110 of 119 posts

Re: MCP vs. API Explained

#101

Post by no_wizard »

vineyardmike wrote: post #68
no_wizard wrote: post #14

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

> If it was truly intelligent it could reason about things like API specifications without any precursors or shared structure, but it can’t I can reason about any API or specification. But when I'm trying to get a different, compound, and higher-level task done, its quite a bit faster and less distracting if I can rely on someone else to have already distilled what I need (into a library, cheat-sheet, tutorial, etc).…

It doesn’t negate my point; the technology can’t self reason any API specification, and if it could this wouldn’t be needed because while humans benefit from this simplification why would a machine that can think 10000x faster than a human can?

Re: MCP vs. API Explained

#102

Post by ondrsh »

mountainriver wrote: post #99
ondrsh wrote: post #11

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…

What does it actually offer over OpenAPI though? If I feed an openapi spec to an LLM it can use it as a tool

It seems like you're describing a scenario where you know at design-time which tools will be included. In that case the benefit of using MCP is less clear.

While you usually get tools that work out of the box with MCP (and thus avoid the hassle of prompting + testing to get working tool code), integrating external APIs manually often results in higher accuracy and performance, as you're not limited by the abstractions imposed by MCP.

Re: MCP vs. API Explained

#103

Post by thierrydamiba »

ondrsh wrote: post #92
thierrydamiba wrote: post #87

Earlier quoted context omitted.

Both blog posts were excellent. Thanks for the breakdown. I’m bullish on MCP-what is are some non-obvious things I shod consider that might dampen my fire?

TL;DR: IMHO, the MCP enforces too much structure, which makes it vulnerable to disruption by less structured protocols that can evolve according to user needs. The key reason the web won out over Gopher and similar protocols was that the early web was stupidly simple. It had virtually no structure. In fact, the web might have been the greatest MVP of all time: it handed server developers a blank canvas with as few ru…

Thanks again for the thorough response.

Re: MCP vs. API Explained

#105

Post by shan-chang »

I'd like to recommend another protocol—ANP (AgentNetworkProtocol).

While similar to MCP, ANP is significantly different. ANP is specifically designed for agents, addressing communication issues encountered by intelligent agents. It enables identity authentication and collaboration between any two agents.

Key differences include:

ANP uses a P2P architecture, whereas MCP follows a client-server model. ANP relies on W3C DID for decentralized identity authentication, while MCP utilizes OAuth. ANP organizes information using Semantic Web and Linked Data principles, whereas MCP employs JSON-RPC. MCP might excel at providing additional information and tools to models and connecting models to the existing web. In contrast, ANP is particularly effective for collaboration and communication between agents.

Here is a detailed comparison of ANP and MCP (including the GitHub repository): https://github.com/agent-network-protocol/AgentNetworkProtoc...

Re: MCP vs. API Explained

#106

Post by notpushkin »

ImPostingOnHN wrote: post #98
notpushkin wrote: post #84

Earlier quoted context omitted.

> I'd argue that an API is not a user interface and that's not really their intention. API is a user interface for other developers – just like MCP is a UI for LLMs.

The U in UI is User, and refers to the human. If something is Interfacing with an Application, and that something is another Application instead of a human , that means the interaction is happening via an Application Interface (to make things easier, we'll call it an AI for short...just kidding) . That seems to be what happens here with MCP: it is a way for an Application (the LLM) to derive programming by Interfacin…

> If something is Interfacing with an Application, and that something is another Application instead of a human, that means the interaction is happening via an Application Interface

My point is, the applications have been (until recently) predominantly written by humans. API is the interface developers use through the code they write. Just like a UI can be better or worse, so can API: it might be concise, expressive, consistent – or verbose, clunky and completely unpredictable. Just like in UI you don’t want to click through dozens of submenus, in API you don’t want to make a dozen of calls to do something simple. It’s way more similar than you think!

Now where MCP fits in here is a whole other question...

Re: MCP vs. API Explained

#107

Post by johnjungles »

cloudking wrote: post #28
johnjungles wrote: post #15

I built https://skeet.build where anyone can try out mcp for cursor and dev tools without a lot of setup Mostly for workflows I like: - start a PR with a summary of what I just did - slack or comment to linear/Jira with a summary of what I pushed - pull this issue from sentry and fix it - pull this linear issue and do a first pass - pull in this Notion doc with a PRD then create an API reference for it based on this…

What is unique about your solution? Are you essentially handling auth tokens for the user to interface MCPs with external APIs?

So there’s a lot of noise about MCP but it’s just a tool - we found that we’re solving for developer workflows (where there’s pain). People want to get shit done but after coding to update JIRA tickets just kills momentum.

We just make it a highly reliable, easy to use, after committing - add a comment with a summary to that Jira/linear issue. Start a PR in GitHub and assign x, update the slack channel with an update.

In order to get this it wasn’t about porting APIs to mcp. It was thoughtfully designing and optimizing for these workflows. Also quality and polish where the calls are highly reliable - required lower level networking optimizations, sessions, etc to make to work smoothly.

But yes, also part of the frictionless experience was, just oauth.

Re: MCP vs. API Explained

#108

Post by ImPostingOnHN »

notpushkin wrote: post #106
ImPostingOnHN wrote: post #98

Earlier quoted context omitted.

The U in UI is User, and refers to the human. If something is Interfacing with an Application, and that something is another Application instead of a human , that means the interaction is happening via an Application Interface (to make things easier, we'll call it an AI for short...just kidding) . That seems to be what happens here with MCP: it is a way for an Application (the LLM) to derive programming by Interfacin…

> If something is Interfacing with an Application, and that something is another Application instead of a human, that means the interaction is happening via an Application Interface My point is, the applications have been (until recently) predominantly written by humans. API is the interface developers use through the code they write. Just like a UI can be better or worse, so can API: it might be concise, expressive,…

> Just like a UI can be better or worse, so can API: it might be concise, expressive, consistent – or verbose, clunky and completely unpredictable. Just like in UI you don’t want to click through dozens of submenus, in API you don’t want to make a dozen of calls to do something simple.

What you're describing are qualities of an interface, as in a User Interface or an Application Interface. You are right that UIs and APIs are similar, because they are both Interfaces. You are right that a good Interface has certain qualities, whether it's a UI or an API. For example, a GraphQL API tries to address the challenge of, "in API you don’t want to make a dozen of calls to do something simple" by consolidating multiple calls into 1.

That said, API is the interface programs use to interact with an application, UI is the interface humans use to interact with a program. Sometimes you get both: A developer interacts with an IDE or text editor (a user interface), and the IDE or text editor interacts with the underlying layer (an application interface).

What you don't see are humans typing bytes to an MCU server, or any other API. Humans are clicking or typing commands into a program via a UI, the program connects to the MCU server via an API, the MCU server connects to, say, a weather server via an API.

Re: MCP vs. API Explained

#109

Post by peab »

ondrsh wrote: post #102
mountainriver wrote: post #99

Earlier quoted context omitted.

What does it actually offer over OpenAPI though? If I feed an openapi spec to an LLM it can use it as a tool

It seems like you're describing a scenario where you know at design-time which tools will be included. In that case the benefit of using MCP is less clear. While you usually get tools that work out of the box with MCP (and thus avoid the hassle of prompting + testing to get working tool code), integrating external APIs manually often results in higher accuracy and performance, as you're not limited by the abstraction…

any API can be modeled as JSON in, JSON out, which you can pass to the system prompt at design time or at runtime, no?

Re: MCP vs. API Explained

#110

Post by immibis »

james_marks wrote: post #96
immibis wrote: post #46

Earlier quoted context omitted.

Then it's a useless concept, because people who use LLMs don't want to be bounded by a whitelist.

Strong disagree. I want absolutely control over what tools my agent can access on my computer.

Do you want your tech landlord to have absolute control over what tools your agent can use on your computer?
Post reply on HN