Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP: An (Accidentally) Universal Plugin System

worksonmymachine.substack.com

Post reply on HN
Print view View original

281–290 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#281

Post by drewnoakes »

edgolub wrote: post #279
thiht wrote: post #275

Earlier quoted context omitted.

Yes I understand that, but how do I write these endpoints myself without using magic @mcp annotations? After like an hour of searching I finally found the Lifecycle page: https://modelcontextprotocol.io/specification/2025-06-18/bas... and I think it contains the answers I’m looking for. But I feel this should be roughly explained in the first introduction. Agree that most of the pages feel LLM generated, and borderli…

The reason why they do not expose the underlying server schema, is because you aren't supposed to write your own MCP server from zero, in the same way you aren't supposed to write your own GraphQL Server from zero. Yes, technically you could, but you are "supposed" to just use a library that builds the actual endpoints based on the schema for the version of MCP you are using. And only worry about building your tools,…

I agree with this, and my preference is generally to use a nice library for such things, but understanding the low level protocol and its capabilities helps me conceptualise the interactions more concretely, and understand more of what a given library is doing for me when I use it. In that way, a clear explanation of a protocol has a lot of value for me.

Re: MCP: An (Accidentally) Universal Plugin System

#282

Post by brabel »

notatoad wrote: post #214
OkGoDoIt wrote: post #178

Earlier quoted context omitted.

Part of the reason AI agents and MCP work is because AI can programmatically at runtime determine what plug-ins to use. Without the AI part, how does the host app know when to call a MCP server function?

same as any other api function call in an app - because an app developer programmed it to call that function.

That only works for the MCPs your app knows about, which is not that great. The usefulness of a plugin system like MCP is that an app can automatically use it. But MCPs are literally just a function, with some metadata about what it does and how to invoke it. The only thing generic enough to figure out how to use a function given only this metadata seems to be an LLM. And not even all of them, only some support “toll calling “.

Re: MCP: An (Accidentally) Universal Plugin System

#283

Post by TeMPOraL »

freeone3000 wrote: post #147
visarga wrote: post #89

Earlier quoted context omitted.

The main benefit is not that it made interoperability fashionable, or that it make things easy to interconnect. It is the LLM itself, if it knows how to wield tools. It's like you build a backend and the front-end is not your job anymore, AI does it. In my experience Claude and Gemini can take over tool use and all we need to do is tell them the goal. This is huge, we always had to specify the steps to achieve anythi…

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.

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.)

Re: MCP: An (Accidentally) Universal Plugin System

#284

Post by TeMPOraL »

Mtinie wrote: post #196
lazyasciiart wrote: post #165

Earlier quoted context omitted.

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.

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.

Re: MCP: An (Accidentally) Universal Plugin System

#285

Post by MomsAVoxell »

phh wrote: post #22

I agree with the article, and I love how the author is (mis-)using MCP. I just want to rephrase what the accident actually is. The accident isn't that somehow we got a protocol to do things we couldn't do before. As other comments point out MCP (the specificaiton), isn't anything new or interesting. No, the accident is that the AI Agent wave made interoperability hype, and vendor lock-in old-fashioned. I don't know h…

All vendor lock in is being transmuted to model access.

Re: MCP: An (Accidentally) Universal Plugin System

#286

Post by seunosewa »

miki123211 wrote: post #211
adregan wrote: post #49

Earlier quoted context omitted.

How ironic given the amount of APIs that were locking down access in response to AI training! Though the general API lockdown was started long before that, and like you, I’m skeptical that this new wave of open access will last if the promise doesn’t live up to the hype.

MCP seems to be about giving you access to your own data . Your Slack conversations, your Jira tickets, your calendar appointments. Those wouldn't go into AI training datasets anyway, locked down APIs or not. The APIs of old were about giving you programmatic access to publicly available information. Public tweets, public Reddit posts, that sort of thing. That's the kind of data AI companies want for training, and yo…

Interesting perspective because MCPs are safer when they give you access to your own content from trusted providers or local apps on your computer than when they give you access to public data which may have prompt injection booby traps.

Re: MCP: An (Accidentally) Universal Plugin System

#287

Post by asteroidburger »

stavros wrote: post #227
bigiain wrote: post #225

Earlier quoted context omitted.

I am pondering if I should do this. If I have a app who's backend needs to connect to, say, a CRM platform - I wonder if instead of writing APIs to connect to Dynamics or Salesforce or Hubspot specifically, if there's benefit in abstracting a CRM interface with an MCP so that switching CRM providers later (or adding additional CRMs) becomes easier?

One of us doesn't understand MCP well enough, and it might very well be me, but how can MCP be used without an LLM? Most of the structure is in human language.

MCP itself doesn't require the use of the LLM. There are other concepts, but for this use, Tools are key. A Tool is an operation, like a search.

Have a look at the Filesystem example MCP server - https://github.com/modelcontextprotocol/servers/blob/main/sr.... It has a collection of Tools - read_file, read_multiple_files, write_file, etc.

The LLM uses MCP to learn what tools the server makes available; the LLM decides when to use them. (The process is a little more complicated than that, but if you're just trying to call tools without an LLM, those parts aren't really important.) If you ask the LLM, "Find all files with an asterisk," it might deduce that it can use the search_files tool provided by that MCP to gain the needed context, invoke that tool, then process the results it returns. As an engineer, you can just call search_files if you know that's what you want.

Re: MCP: An (Accidentally) Universal Plugin System

#288

Post by mike_hearn »

troupo wrote: post #276
tveita wrote: post #176

Earlier quoted context omitted.

There is a long tail of applications that are not currently scriptable or have a public API. The kind that every so often make you think "if only I could automate this instead of clicking through this exact same dialog 25 times" Before, "add a public API to this comic reader/music player/home accounting software/CD archive manager/etc." would be a niche feature to benefit 1% of users. Now more people will expect to h…

> There is a long tail of applications that are not currently scriptable or have a public API. So how does MCP help with this?

The theory is, I guess, that creating an MCP API is a lot easier than creating a regular API. A regular API is a very costly thing to develop and it has on-going costs too because it's so hard to change. You have to think about data structures, method names, how to expose errors, you have to document it, make a website to teach devs how to use it, probably make some SDKs if you want to do a good job, there's authentication involved probably, and then worst of all: if you need to change the direction of your product you can't because it'd break all the connected apps.

An MCP API dodges all of that. You still need some data structures but beyond that you don't think too hard, just write some docs - no fancy HTML or SDKs needed. MCP is a desktop-first API so auth mostly stops being an issue. Most importantly, if you need to change anything you can, because the LLM will just figure it out, so you're way less product constrained.

Re: MCP: An (Accidentally) Universal Plugin System

#289

Post by stavros »

asteroidburger wrote: post #287
stavros wrote: post #227

Earlier quoted context omitted.

One of us doesn't understand MCP well enough, and it might very well be me, but how can MCP be used without an LLM? Most of the structure is in human language.

MCP itself doesn't require the use of the LLM. There are other concepts, but for this use, Tools are key. A Tool is an operation, like a search. Have a look at the Filesystem example MCP server - https://github.com/modelcontextprotocol/servers/blob/main/sr... . It has a collection of Tools - read_file, read_multiple_files, write_file, etc. The LLM uses MCP to learn what tools the server makes available; the LLM decid…

That's my understanding as well, but you'll be missing the discovery part. You'll have to hardcode the API, at which point you may as well just use the computer API the MCP also uses under the hood.

Re: MCP: An (Accidentally) Universal Plugin System

#290

Post by alex-moon »

I always say this whenever anyone asks about whether something is "just hype". One day I will write a blog post on it. Long story short: every piece of new tech is "just hype" until the surrounding ecosystem is built for it. Trains are just hype until you cover the country in railway lines. Telephony is just hype until everyone has a telephone. Email is just hype until everyone has a personal computer (and a reason to sit in front of it every day).

Typically, in these kinds of developments there are two key things that need to appear at the same time: 1. Ubiquitous hardware, so e.g. everyone buys a car, or a TV, or a toaster. 2. An "interface" (whether that's a protocol or a UI or an API or a design standard) which is hyper low cognitive load for the user e.g. the flush button on a toilet is probably the best example I've ever seen, but the same can be said for the accelerator + brake + steering wheel combo, or indeed in digital/online it's CSV for me, and you can also say the same about HTTP like this article does.

Obviously these two factors feed into each other in a kind of feedback loop. That is basically what the role of "hype" is, to catalyse that loop.

Post reply on HN