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

111–119 of 119 posts

Re: MCP vs. API Explained

#111

Post by ondrsh »

peab wrote: post #109
ondrsh wrote: post #102

Earlier quoted context omitted.

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?

I'm not sure I fully understand your scenario. Who will be doing the actual network requests?

MCP is basically a trifecta of:

  1) MCP-aware LLM applications
  2) MCP clients
  3) MCP servers
The LLM application is key here. It is doing all the "plumbing", like spawning MCP clients to connect to MCP servers — similar to how your web browser is spawning HTTP clients to connect to HTTP servers. The LLM application thus initiates and receives the actual requests between MCP client and MCP server, manages MCP client/server pairs, injects tool results into the LLM context et cetera. This means the LLM application must be MCP-aware at design-time. But because all of this plumbing can then happen at runtime under the hood, the user (who adds MCP tools while the application is running) does not need to be a developer.

As a developer, MCP allows you to write:

  1) MCP-aware LLM applications
  2) MCP servers
MCP-aware LLM applications (like Claude Desktop or Cursor) let their users add arbitrary functionality (i.e. other MCP servers) at runtime.

MCP servers can be added by users of MCP-aware LLM applications at runtime.

Both evolve around the concept of giving non-developers a way to add functionality at runtime. Most developers are confused about MCP because they don't need to do neither 1) nor 2), instead they themselves add tools to the applications they write (at design-time) and then ship it.

Re: MCP vs. API Explained

#112

Post by ondrsh »

yourapostasy wrote: post #94
ondrsh wrote: post #92

Earlier quoted context omitted.

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…

Under this thesis, then SLOP would win, except I don’t yet see how it can be composed by the user, which MCP is supposed to have moved the composability into? https://i-love-slop.com/

Seems nice because it's stateless and thus simpler. But it still enforces lots of structure (static entry points, memory, etc.). So if MCP reminds me of FTP/Telnet (bi-directional, stateful), SLOP reminds me of Gopher.

In any case, protocols need killer applications to take off — for the web this killer app was Mosaic. Right now I don't see any application supporting SLOP. If they are able to come up with one that outperforms other MCP-based LLM applications, they will have a chance.

My personal belief is that the winning protocol will be web-like. Right now there is no such protocol. Maybe I'm wrong, let's see.

Re: MCP vs. API Explained

#113

Post by james_marks »

immibis wrote: post #110
james_marks wrote: post #96

Earlier quoted context omitted.

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?

As I understand it, I maintain the whitelist, not the tech overlord.

That’s sort of the point of MCP, as near as I can tell.

Re: MCP vs. API Explained

#114

Post by PeterBrink »

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…

Hey ondrsh, I read your blog post and thought it was very interesting, however I did have a follow-up question:

In your post you say "The key insight is: Because this can happen at runtime, the user (NOT the developer) can add arbitrary functionality to the application (while the application is running — hence, runtime). And because this also works remotely, it could finally enable standardized b2ai software!"

That makes sense, but my question is: how would the user actually do that? As far as I understand, they would have to somehow pass in either a script to spin up their own server locally (unlikely for your everyday user), or a url to access some live MCP server. This means that the host they are using needs an input on the frontend specifically for this, where the user can input a url for the service they want their LLM to be able to talk to. This then gets passed to the client, the client calls the server, the server returns the list of available tools, and the client passes those tools to the LLM to be used.

This is very cool and all, but it just seems like anyone who has minimal tech skills would not have the patience to go and find the MCP server url of their favourite app and then paste it into their chatbot or whatever they're using.

Let me know if I have misunderstood anything, and thanks in advance!

Re: MCP vs. API Explained

#115

Post by ondrsh »

PeterBrink wrote: post #114
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…

Hey ondrsh, I read your blog post and thought it was very interesting, however I did have a follow-up question: In your post you say "The key insight is: Because this can happen at runtime, the user (NOT the developer) can add arbitrary functionality to the application (while the application is running — hence, runtime). And because this also works remotely, it could finally enable standardized b2ai software!" That m…

Your understanding is on point.

> As far as I understand, they would have to somehow pass in either a script to spin up their own server locally (unlikely for your everyday user), or a url to access some live MCP server. This means that the host they are using needs an input on the frontend specifically for this, where the user can input a url for the service they want their LLM to be able to talk to. This then gets passed to the client, the client calls the server, the server returns the list of available tools, and the client passes those tools to the LLM to be used.

This is precisely how it would work. Currently, I'm not sure how many host applications (if any) actually feature a URL input field to add remote servers, since most servers are local-only for now. This situation might change once authentication is introduced in the next protocol version. However, as you pointed out, even if such a URL field existed, the discovery problem remains.

But discovery should be an easy fix, in my opinion. Crawlers or registries (think Google for web or Archie for FTP) will likely emerge, so host applications could integrate these external registries and provide simple one-click installs. Apparently, Anthropic is already working on a registry API to simplify exactly this process. Ideally, host applications would automatically detect when helpful tools are available for a given task and prompt users to enable them.

The problem with local-only servers is that they're hard to distribute (just as local HTTP servers are) and that sandboxing is an issue. One workaround is using WASM for server development, which is what mcp.run is doing (https://docs.mcp.run/mcp-clients/intro), but of course this breaks the seamless compatibility.

Re: MCP vs. API Explained

#116

Post by PeterBrink »

ondrsh wrote: post #115
PeterBrink wrote: post #114

Earlier quoted context omitted.

Hey ondrsh, I read your blog post and thought it was very interesting, however I did have a follow-up question: In your post you say "The key insight is: Because this can happen at runtime, the user (NOT the developer) can add arbitrary functionality to the application (while the application is running — hence, runtime). And because this also works remotely, it could finally enable standardized b2ai software!" That m…

Your understanding is on point. > As far as I understand, they would have to somehow pass in either a script to spin up their own server locally (unlikely for your everyday user), or a url to access some live MCP server. This means that the host they are using needs an input on the frontend specifically for this, where the user can input a url for the service they want their LLM to be able to talk to. This then gets…

Amazing, that makes a lot of sense. The idea of having one-click installs is very cool. I still think for the every day consumer it might be a small roadblock that they still have to know what tools to use before being able to use them, and having that tool suggestion mechanism you mentioned would really bring everything together.

Thanks for the awesome feedback, and congrats on the blog posts by the way, they are a great read!

Re: MCP vs. API Explained

#117

Post by frabjoused »

saurik wrote: post #69
frabjoused wrote: post #52

Earlier quoted context omitted.

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?

> This is very naive. How many different APIs have you authenticated with and connected to? Just the big ones? I mean, a lot? I have multiple times felt like that was my entire life for weeks or months on end during the past over three decades of doing software development... (If we expand the scope a bit to network protocols, as opposed to just "APIs", I was even the person who first spiked nmap's protocol scanning…

Congrats on the bug bounties!

I’m not hyping or defending MCP at all: I’m just saying AI can’t figure out APIs well enough to be something you can promise as a product.

I founded an integration platform so definitely a developer and I’ve been living these problems every day.

Re: MCP vs. API Explained

#118

Post by josvdwest »

PeterBrink wrote: post #116
ondrsh wrote: post #115

Earlier quoted context omitted.

Your understanding is on point. > As far as I understand, they would have to somehow pass in either a script to spin up their own server locally (unlikely for your everyday user), or a url to access some live MCP server. This means that the host they are using needs an input on the frontend specifically for this, where the user can input a url for the service they want their LLM to be able to talk to. This then gets…

Amazing, that makes a lot of sense. The idea of having one-click installs is very cool. I still think for the every day consumer it might be a small roadblock that they still have to know what tools to use before being able to use them, and having that tool suggestion mechanism you mentioned would really bring everything together. Thanks for the awesome feedback, and congrats on the blog posts by the way, they are a…

I guess if someone like Anthropic builds a proper registry, then the user wouldn't have to decide and the AI can decide itself?

Re: MCP vs. API Explained

#119

Post by josvdwest »

starik36 wrote: post #8

It seems like MCP is a pretty cool protocol, but has anyone seen any actually useful integrations? I've played a lot with the FileSystem MCP server but couldn't get it to do something useful that I can't already do faster on my own. For instance, asking it how many files have word "main" in it. It returns 267, but in reality there are 12k. Looks promising, but I am still looking for useful ways to integrate it into m…

I've found it useful for controlling Unity from within Cursor while doing game development.
Post reply on HN