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

271–280 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#271

Post by troupo »

thiht wrote: post #270

Can someone help me find an actual explanation of what MCP does? The official MCP documentation completely fails at explaining how it works and what it does. For example the quick start for server developers[1] doesn’t actually explain anything. Sure in the Python examples they add @mcp annotations but WHAT DOES IT DO? I feel like I’m going crazy reading their docs because there’s nothing of substance in there. Let’s…

MCP is a server that exposes API endpoints (new vibe term is "tools")

MCP clients can query these endpoints (new vibe term is "invoke tools")

That is almost the entirety of it.

The difference with traditional API endpoints is: they are geared towards LLMs, so LLMs can ask servers to list "tools" and can call these tools at will during execution.

It's a vibe-coded spec for an extremely hype-based space.

Re: MCP: An (Accidentally) Universal Plugin System

#272

Post by opliko »

doug_durham wrote: post #170
gavinray wrote: post #144

Earlier quoted context omitted.

WSDL + XML API's have been around since 1998. OpenAPI, OData, gRPC, GraphQL I'm sure I'm missing a few...

Where is "list-tools" in any of those low level protocols?

I don't know enough about OData, but:

- Introspection (__schema queries) for every graphQL server. You can even see what it exposes because most services expose a web playground for testing graohQL APIs, e.g. GitHub: https://docs.github.com/en/graphql/overview/explorer

- Server Reflection for gRPC, though here it's optional and I'm not aware of any hosted web clients, so you'll need a tool like gRPCCurl if you want to see how it looks in real services yourself.

- OpenAPI is not a protocol, but a standard for describing APIs. It is the list-tools for REST APIs.

Re: MCP: An (Accidentally) Universal Plugin System

#273

Post by troupo »

sshine wrote: post #27
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…

Hype, certainly. But the way I see it, AI agents created incentives for interoperability. Who needs an API when everyone is job secure via being a slow desktop user? Well, your new personal assistant who charges by the Watt hour NEEDS it. Like when the CEO will personally drive to get pizzas for that hackathon because that’s practically free labor, so does everyone want everything connected. For those of us who rode…

> But the way I see it, AI agents created incentives for interoperability.

There are no new incentives for interoperability. Compare that were already providing API access added MCP servers of varying quality.

The rest couldn't care less, unless they can smell an opportunity to monetize hype

Re: MCP: An (Accidentally) Universal Plugin System

#274

Post by troupo »

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.

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

Re: MCP: An (Accidentally) Universal Plugin System

#275

Post by thiht »

troupo wrote: post #271
thiht wrote: post #270

Can someone help me find an actual explanation of what MCP does? The official MCP documentation completely fails at explaining how it works and what it does. For example the quick start for server developers[1] doesn’t actually explain anything. Sure in the Python examples they add @mcp annotations but WHAT DOES IT DO? I feel like I’m going crazy reading their docs because there’s nothing of substance in there. Let’s…

MCP is a server that exposes API endpoints (new vibe term is "tools") MCP clients can query these endpoints (new vibe term is "invoke tools") That is almost the entirety of it. The difference with traditional API endpoints is: they are geared towards LLMs, so LLMs can ask servers to list "tools" and can call these tools at will during execution. It's a vibe-coded spec for an extremely hype-based space.

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 borderline unreadable

Re: MCP: An (Accidentally) Universal Plugin System

#276

Post by troupo »

tveita wrote: post #176
therein wrote: post #136

Earlier quoted context omitted.

So the whole point of the article is that an API is an API and anything can call an API?

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?

Re: MCP: An (Accidentally) Universal Plugin System

#277

Post by troupo »

thiht wrote: post #275
troupo wrote: post #271

Earlier quoted context omitted.

MCP is a server that exposes API endpoints (new vibe term is "tools") MCP clients can query these endpoints (new vibe term is "invoke tools") That is almost the entirety of it. The difference with traditional API endpoints is: they are geared towards LLMs, so LLMs can ask servers to list "tools" and can call these tools at will during execution. It's a vibe-coded spec for an extremely hype-based space.

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…

I would use Elixir and ash_ai :)) https://youtu.be/PSrzruaby1M?si=EEEQtQPOSMaLFJcM

(Sorry, I know this isn't really a helpful answer)

Re: MCP: An (Accidentally) Universal Plugin System

#278

Post by brabel »

SoftTalker wrote: post #152
mh- wrote: post #50

Earlier quoted context omitted.

Unfortunately, I think we're equally likely to see shortsighted lock-in attempts like this [0] one from Slack. I tried to find a rebuttal to this article from Slack, but couldn't. I'm on a flight with slow wifi though. If someone from Slack wants to chime in that'd be swell, too. I've made the argument to CFOs multiple times over the years why we should continue to pay for Slack instead of just using Teams, but y'all…

Sounds sort of like an innovator's dilemma response. New technology appears and the response is gatekeeping and building walls rather than adaptation.

Slack was never an innovator. By the time they showed up there were lots of chats apps. They just managed to go beyond the others by basically embedding a browser engine into their app at a time most thought of that as heresy, I mean a chat app that requires 1Gb to run was a laughable proposition to us, techies. But here we are… MS Teams is even heavier, but users seem to care nothing about that anyway.

Re: MCP: An (Accidentally) Universal Plugin System

#279

Post by edgolub »

thiht wrote: post #275
troupo wrote: post #271

Earlier quoted context omitted.

MCP is a server that exposes API endpoints (new vibe term is "tools") MCP clients can query these endpoints (new vibe term is "invoke tools") That is almost the entirety of it. The difference with traditional API endpoints is: they are geared towards LLMs, so LLMs can ask servers to list "tools" and can call these tools at will during execution. It's a vibe-coded spec for an extremely hype-based space.

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, to expose them to a LLM, so it can be consumed (LLM function calling, but with lots of abstractions to make it more developer friendly)

Re: MCP: An (Accidentally) Universal Plugin System

#280

Post by brabel »

bigiain wrote: post #235
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.

I will also freely admit to not understanding MCP much, but using it without an LLM was (at least to my reading) pretty much the main thesis of the linked article. "Okay but. But. What if you just... removed the AI part? What if it's just "a standardized way to connect literally anything to different data sources and tools"?" (which had struck out text 'AI models' in between 'connect' and 'literally')

You’re right. It’s unclear, however, how your application will handle knowing when to call a tool/MCP. That’s the part where LLMs are so good at: understanding that to do a certain job, this or that tool would be useful, and then knowing how to provide the necessary parameters for the tool call (I say tool here because MCP is just a convenient way to pack a normal tool, in other words, it’s a plugin system for tools).
Post reply on HN