Hacker News Reader

Comment by Animats | Hacker News Reader

> Want spell check? MCP server.

> Want it to order coffee when you complete 10 tasks? MCP server.

With a trip through an LLM for each trivial request? A paid trip? With high overhead and costs?

the whole point of the article is that it doesn't need to be an LLM, MCP is just a standard way to expose tools to things that use tools. LLMs can use tools, but so can humans.

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

Maybe phrasing it this way will be the lightbulb moment for everyone who hasn’t got that yet.

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 hook up their AI assistant of choice, so the feature can be prioritized.

The early MCP implementations will be for things that already have an API, which by itself is underwhelming.

You would think Apple would have a leg up here with AppleScript already being a sanctioned way to add scriptable actions across the whole of macOS, but as far as I can tell they don't hook it up to Siri or Apple Intelligence in any way.

That's not where the money is. It's in adding a toll charge for tokens to talk to widely used APIs.

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

I see the point as "let's not overcomplicate the API with complex schemas and such. Lets not use GraphQL for everything. Just create a simple API and call it to extend stuff. Am I wrong?

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

Same way it would call any other api: exactly when it was programmed to.

Reply on news.ycombinator.com