Live data from Hacker News

The Future of MCPs

iamcharliegraham.substack.com

71–80 of 90 posts

Re: The Future of MCPs

#71

If LLMs are so smart, why do they need a custom "MCP" format to what's commonly known as a normal API? Why can't they just call normal APIs? Extending this thought: why would there be any difference between offering data behind an API, and offering data behind a "MCP api"? At the end of the day, the underlying data will be the same (weather, stock market info, logs, whatever), it seems LLMs just needs this to be "sta…

Well, LLMs are not so smart for starters.

Re: The Future of MCPs

#72
post #66
post #34

Earlier quoted context omitted.

I'd expect "local MCP servers" will be generally installed as part of something else. Photoshop, or Outlook, or whatever could come with a local MCP server to allow chat clients to automate them. Maybe printer drivers or other hardware would do similar. I don't think there's much reason to install a cloud service MCP server to run locally; you'd just use the one provided in the cloud.

Interesting thought. But maybe the companies would actually like to at least pipe the communication throught the cloud to get all the usage data. Here's one possible architecture: local chat client - talks to cloud LLM - talks to local MCP servers local MCP server provided by company - connects to company cloud (this lets the company collect usage data) - forwards tasks to the cloud local tool (for example photoshop)…

Hmm, in that example the MCP server is just a thin api wrapper though, so it wouldn't change anything by running locally, right? Like I could see where maybe a TikTok MCP server would benefit from running locally since that would allow it to expose a camera api, but I can't think of anything you could do with a local Airbnb MCP server that you couldn't do with a cloud one.

Nefariously, I guess since these things would be running in the background continuously, that would provide another avenue for companies to spy on you, so that may be a reason companies create local mcps even if there's no other reason to.

Re: The Future of MCPs

#73

If LLMs are so smart, why do they need a custom "MCP" format to what's commonly known as a normal API? Why can't they just call normal APIs? Extending this thought: why would there be any difference between offering data behind an API, and offering data behind a "MCP api"? At the end of the day, the underlying data will be the same (weather, stock market info, logs, whatever), it seems LLMs just needs this to be "sta…

They actually can. I have found myself getting more use out of a terminal MCP and providing OpenAPI specs than bespoke MCP servers.

Bespoke MCP's right now are a convenience.

Re: The Future of MCPs

#74
post #72
post #66

Earlier quoted context omitted.

Interesting thought. But maybe the companies would actually like to at least pipe the communication throught the cloud to get all the usage data. Here's one possible architecture: local chat client - talks to cloud LLM - talks to local MCP servers local MCP server provided by company - connects to company cloud (this lets the company collect usage data) - forwards tasks to the cloud local tool (for example photoshop)…

Hmm, in that example the MCP server is just a thin api wrapper though, so it wouldn't change anything by running locally, right? Like I could see where maybe a TikTok MCP server would benefit from running locally since that would allow it to expose a camera api, but I can't think of anything you could do with a local Airbnb MCP server that you couldn't do with a cloud one. Nefariously, I guess since these things woul…

Well maybe a local Airbnb MCP could have access to your phone to call the host. Or to your wallet to pay.

That may make more sense than having a separate "wallet MCP server" running locally and having the LLM coordinate the transaction. While the premise of MCP is to allow LLMs to do such things, idk if I want an LLM to be hallucinating with my credit card.

Re: The Future of MCPs

#75
post #29
post #22

Earlier quoted context omitted.

No, but let me be more specific. For example, when I search for flights, there might be situational things (like, "can you please find me a flight that has at least a 2 hour layover at airport because last time i had a hard time finding the new terminal" etc. Or an agent that will actually even READ that information from the airport website to see notices like "expect long delays in the next 3 months as we renovate T…

So, Yahoo! Pipes, but with magic and wishful thinking

Also RAG. Pipes just consumed APIs, IIRC. SOAP at that.

But definitely web mashups all over again.

Re: The Future of MCPs

#76
post #61

Earlier quoted context omitted.

I had the exact same reaction to the plural "MCPs". That's silly wording. There are no multiple MCPs. It's a single protocol. It's hilariously awkward wording to say you built "an MCP". It's like saying you built "an FTP", or "an HTTP". I guess every Web App is really just "an HTTP". We've been talking wrong all these years. lol.

On the other hand, IP addresses have crossed into the popular lexicon in exactly this manner… it’s common enough to hear people say “what’s my “ip?” or “are there any free ips?” or what are the IPs for x/y/z”. I agree that it sounds stupid and incorrect, but that doesn’t necessarily mean using MCP as a metonym for MCP server.

Good point. Other examples are Wi-Fi (e.g. "What's your Wi-Fi?"), DNS (e.g. "You should change your DNS") and USB (e.g. "I only have 2 USBs on my laptop"). So who knows, maybe "MCPs" will catch-on.

Re: The Future of MCPs

#77
post #32
post #11

> Think of MCPs as standardized APIs—connectors between external data sources or applications and large language models (LLMs) like ChatGPT or Claude. This is incorrect. MCP is Model Context Protocol. You didn't "build an MCP", you implemented an MCP server. Lighttpd is not "an HTTP", it's an HTTP server. wget is also not "an HTTP", it's an HTTP client. Lighttpd and wget are different enough that it's useful to make…

“The map is not the territory.”

I've actually been thinking about this recently in the context of video games and virtual worlds in general, where when we speak about "the map", we are literally referring to the (virtual) territory. The more we digitize things, the more this distinction breaks down.

Re: The Future of MCPs

#78

If LLMs are so smart, why do they need a custom "MCP" format to what's commonly known as a normal API? Why can't they just call normal APIs? Extending this thought: why would there be any difference between offering data behind an API, and offering data behind a "MCP api"? At the end of the day, the underlying data will be the same (weather, stock market info, logs, whatever), it seems LLMs just needs this to be "sta…

I also did not get it, but now I get it a bit, I think.

Look at it this way. You have to get some work done - maybe book a flight ticket. So you go to two sites - first you go to flight fare comparison, then you book the ticket on the airline website. And you have to do it in code.

There are two ways you can do it.

First Way 1. Understand the API of the flight comparison portal. 2. Understand the API for the airline website. 3. Write code which combines both these API and does the task.

Second Way 1. Message a coder friend who knows the API of the flight comparison portal and ask him to write code to get the cheapest flight. 2. Message another coder friend who knows the API of the airline portal and ask him to book a flight.

Both ways are possible, but which one do you think is Less Work ? Which one is 'cognitively' easier ? Which one can you do while driving a car with one hand ?

It should be clear that the second way is easier. Not only is the second way easier, but if the task requires multiple providers and a lot of context, it might be the only way possible.

The first way is analogous to LLM's doing API calls. The second way is analogous to LLM's doing MCP Servers. MCP servers reduce the cognitive cost to do a task to the LLM - which dramatically increases their power.

Re: The Future of MCPs

#79
post #11

> Think of MCPs as standardized APIs—connectors between external data sources or applications and large language models (LLMs) like ChatGPT or Claude. This is incorrect. MCP is Model Context Protocol. You didn't "build an MCP", you implemented an MCP server. Lighttpd is not "an HTTP", it's an HTTP server. wget is also not "an HTTP", it's an HTTP client. Lighttpd and wget are different enough that it's useful to make…

Purists perpetually decry the zeitgeist's sloppy terminology.

Words that climb the Zipf curve get squeezed for maximum compression, even at the cost of technical correctness. Entropy > pedantry. Resisting it only Streisands the shorthand.

Re: The Future of MCPs

#80
post #25

Earlier quoted context omitted.

I’d just like to interject for a moment. What you’re refering to as Linux, is in fact, GNU/Linux, or as I’ve recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX. Many computer users run a modifi…

Hey look I found the individual willing to die on the "ATM Machine" / "NIC card" hill!

I prefer “AT Machine”, then nobody can tell whether you’re talking about Automated Teller, All-Terrain, or Anti-Tank.

And that’s how you get them.

Post reply on HN