The issue holding us back was never that we had to write a frontend — it was the data locked behind proprietary databases and interfaces. Gated behind API keys and bot checks and captchas and scraper protection. And now we can have an MCP integrator for IFTTT and have back the web we were promised, at least for a while.

what is IFTTT ?

If this then that - a zapier type glue provider.

Minor chronological point but Zapier is an IFTTT-type glue provider.

IFTTT was announced Dec. 14, 2010 and launched on Sept. 7. 2011.

Zapier was first pitched Sept. 30, 2011 and their public beta launched May 2012.

And to answer the obvious next question: yes, there is an MCP for IFTTT https://mcp.pipedream.com/app/ifttt

It’s more useful the other way :p

Minor point but arguably both are Yahoo Pipes-type glue provider, which itself is basic no-code glue thing. The difference is that IFTTT erred on the side of dumbing the product down too much, and Zapier erred on the side of being too much B2B-focused - so they both missed the mark on becoming the universal glue.

Then of course we have Node-Red too, which probably is too developer focused (and generally just lacking any sort of focus at the same time, strangely), so also doesn't sit somewhere closer to the middle.

Do we really not having anything coming close to the usefulness of Yahoo Pipes yet? What would a modern alternative look like and how would it work? Someone has to thinking about this.

If we're considering Node-Red, it would not be amiss to also mention N8N - which, mirroring the IFTTT/Zapier split, is basically the opposite of Node-Red on the "let's turn this into an enterprise product" scale.

> Do we really not having anything coming close to the usefulness of Yahoo Pipes yet?

I don't know of anything. There's some new products I saw heavily promoted on LinkedIn, but at first glance they feel like IFTTT with a shiny coat of paint.

> What would a modern alternative look like and how would it work?

At this point I think ComfyUI or the node editor in Blender would be the best; they're oriented for different kinds of workflows, but UIs of both are excellent in their own ways, and the rest is a matter of implementing the right blocks.

But zapier is easily Google-able and therefore useful as a reference name even if the commenter hasn't heard of it.

Not as easily Goolge’d as “IFTTT” with five characters versus six.

So... How do MCPs magically unlock data behind proprietary databases and interfaces?

It doesn't do it magically. The "tools" an LLM agent calls to create responses are typically REST APIs for these services.

Previously, many companies gated these APIs but with the MCP AI hype they are incentivized to expose what you can achieve with APIs through an agent service.

Incentives align here: user wants automations on data and actions on a service they are already using, company wants AI marketing, USP in automation features and still gets to control the output of the agent.

> Previously, many companies gated these APIs but with the MCP AI hype they are incentivized to expose what you can achieve with APIs through an agent service.

Why would they be incentivized to do that if they survived all the previous hype waves and still have access gated?

> user wants automations on data and actions on a service they are already using,

How many users want that? Why didn't companies do all this before, since the need for automation has always been there?

> Why would they be incentivized to do that if they survived all the previous hype waves and still have access gated?

Because they suddenly now don't want to be left out of the whole AI hype/wave.

Is it stupid? Yes. Can we still reap the benefits of these choices driven by stupid motivations? Also yes.

> Because they suddenly now don't want to be left out of the whole AI hype/wave.

https://news.ycombinator.com/item?id=44405491 and https://news.ycombinator.com/item?id=44408434

Indeed, the frontend itself is usually the problem. If not for data lock in, we wouldn't need that many frontends in the first place - most of the web would be better operated through a few standardized widgets and a spreadsheet and database interfaces - and non-tech people would be using it and be more empowered for it.

(And we know that because there was a brief period in time where basics of spreadsheets and databases were part of curriculum in the West and people had no problem with that.)

I don't understand what you mean.

> It (the main benefit?) is the LLM itself, if it knows how to wield tools.

LLMs and their ability to use tools are not a benefit or feature that arose from MCP. There has been tool usage/support with various protocols and conventions way before MCP.

MCP doesn't have any novel aspects that are making it successful. It's relatively simple and easy to understand (for humans), and luck was on Anthropic's side. So people were able to quickly write many kinds of MCP servers and it exploded in popularity.

Interoperability and interconnecting tools, APIs, and models across providers are the main benefits of MCP, driven by its wide-scale adoption.

To me it feels like an awkward API that creates opportunities to work the limitations of a normal API... which to me is not a great thing. Potentially useful, sure, but not great.