← Back to context

Comment by bustodisgusto

3 days ago

Yea, I am planning a dev build of MCP-B which has access to user scripts apis. So technically you could `vibe code` and inject an MCP server into the target webpage

In the long run (well, mid-run), it'll be about the only way in which it'll be useful: toying with MCPs is all the rage now, but that'll end once business people pause and think for five seconds about what MCP actually does. Which is, provide users with ability to use a service the way they like, not the way the service owners likes, and avoiding interacting with the service directly.

Or, in other words, it helps users get around all the bullshit that actually makes money for the business. Ads, upsells, cross-marketing opportunities. Engagement. LLMs help users avoid all that, and adding an MCP to your site makes it trivial for them.

Maybe I'm too cynical, but think about this: the technologies we needed for this level of automation became ubiquitous decades ago. This was, after all, also the original hype behind APIs, that burned bright on the web for a year or two - before everyone realized that letting people interact with webservices the way they want is bad for business, and everything closed down behind contracts backed by strong auth. Instead of User Agents connecting diverse resources of the web for the benefit of users, we got... Zapier. That's what the future of service-side MCPs on the web is.

But user scripts were always a way to let at least power users show a middle finger to "attention economy" and force some ergonomy out of web apps that desperately try to make users waste time. Giving users the ability to turn any website into MCP, regardless of whether that website wants it, will supercharge this. So for better or worse, that's where the future is.

Adversarial interoperability remains the name of the game.