Comment by jjfoooo4 | Hacker News Reader

Comment by jjfoooo4 | Hacker News Reader

It's very hard for me to understand what MCP solves aside from providing a quick and dirty way to prototype something on my laptop.

If I'm building a local program, I am going to want tighter control over the toolsets my LLM calls have access to.

E.g. an MCP server for Google Calendar. MCP is not saving me significant time - I can access the same API's the MCP can. I probably need to carefully instruct the LLM on when and how to use the Google Calendar calls, and I don't want to delegate that to a third party.

I also do not want to spin up a bunch of arbitrary processes in whatever runtime environment the MCP is written in. If I'm writing in Python, why do I want my users to have to set up a typescript runtime? God help me if there's a security issue in the MCP wrapper for language_foo.

On the server, things get even more difficult to justify. We have a great tool for having one machine call a process hosted on another machine without knowing it's implementation details: the RPC. MCP just adds a bunch of opinionated middleware (and security holes)

I agree vehemently, I'm sort of stunned how...slow...things are in practice. I quit my job 2 years ago to do LLM client stuff and I still haven't made it to Google calendar. It's handy as a user to have something to plug holes in the interim.

In the limit, I remember some old saw about how every had the same top 3 rows of apps on their iPhone homescreen, but the last row was all different. I bet IT will be managing, and dev teams will make, their own bespoke MCP servers for years to come.

If I understand your point correctly - the main bottleneck for tool-calling/MCP is the models themselves being relatively terrible at tool-calling anything but the tools they were finetuned to work with until recently. Even with the latest developments, any given MCP server has a variable chance of success just due to the nature of LLM's only learning the most common downstream tasks. Further, LLM's _still_ struggle when you give them too many tools to call. They're poor at assessing the correct tool to use when given tools with overlapping functionality or similar function name/args.

This is what people mean when they say that MCP should maybe wait for a better LLM before going all-in on this design.

Not in my opinion, works fine in general, wrote 2500 lines of tests for me over about 30 min tonight.

To your point that this isn't trivial or universal, there's a sharp gradient that you wouldn't notice if you're just opining on it as opposed to coding against it -- ex. I've spent every waking minute since mid-December on MCP-like territory, and it still bugs me out how worse every model is than Claude at it. It sounds like you have similar experience, though, perhaps not as satisfied with Claude as I am.

A fair point I suppose. I'm not entirely inexperienced with it, but it does sound like you have more experience with it than I do.

> you wouldn't notice if you're just opining on it as opposed to coding against it

Maybe i'm being sensitive but that is perhaps not the way I would have worded that as it reads a bit like an insult. Food for thought.

What I don't get is why all the MCPs I've seen so far are commands instead of using the HTTP interface. Maybe I'm not understanding something, but with that you could spin up 1 server for your org and everyone could share an instance without messing around with different local toolchains

If there isn't an MCP proxy yet, I'm sure there will be soon. The problem with doing that more widely so far has been that the authentication story hasn't been there yet.

It’s because auth was a pain and people were hiding that in the command. That’s getting better though.

HTTP MCP servers is generally where the trend is moving, now that authentication/authorization in the spec is getting into shape.

That most MCP usage you'll find out in repositories in the wild is focused on local toolchains is mostly due to MCP on launch being essentially only available via the Claude Desktop client. There they also highlighted many local single-user use-cases (rather than organizational ones). That SSE support was also spotty in most implementations also didn't help.

> It's very hard for me to understand what MCP solves

It's providing a standardized protocol to attach tools (and other stuff) to agents (in an LLM-centric world).

The advantage of MCP over fixed flows controlled from backend is that the LLM does the orchestration itself, for example when doing web searches it can rephrase the query as needed and retry until it finds the desired information. When solving a bespoke problem in CLI it will use a number of tools, and call them in the order required by the task at hand. You can't do that easily with a fixed flow.

It is a protocol. If I have to list a bunch of files on my system I don't call a rest server. Same way mcp is not for you doing your stuff. It is for other people do to stuff on your server by the way of tools.

Reply on news.ycombinator.com