Hacker News Reader

Comment by bob1029 | Hacker News Reader

I am really struggling with what the value-add is with MCP. It feels like another distraction in the shell game of contemporary AI tech.

> MCP is an open protocol that standardizes how applications provide context to LLMs.

What is there to standardize? Last I checked, we are using a text-to-text transformer that operates on arbitrary, tokenized strings. Anything that seems fancier than tokens-to-tokens is an illusion constructed by the marketing wizards at these companies. Even things like tool/function calling are clever heuristics over plain-ass text.

> Currently, the MCP spec defines two kinds of servers, based on the transport mechanism they use: ...

This looks like micro services crossed with AI. I don't think many are going to have a happy time at the end of this adventure.

View on HN

If you're interested, I'd encourage you to implement an MCP integration and see if you change your mind.

For instance, I have a little 'software team in a box' tool. v1 integrated github and three different llms manually (react + python backend). This is fine. You can call github commands via CLI on the backend, and add functionality somewhat easily, depending on the LLM's knowledge.

Pain points -- if you want workflow to depend on multiple outputs from these pieces, (e.g. see that there's a pull request, and assess it, or see that a pull request is signed off on / merged, and update something) -- you must code most of these workflows manually.

v2, I wiped that out and have a simple git, github and architect MCP protocol written up. Now I can have claude as a sort of mastermind, and just tell it "here are all the things you can do, please XXX". It wipes out most of the custom workflow coding and lets me just tell Claude what I'd look to do -- on the backend, my non-LLM MCP server can deal with things it's good at, API calls, security checks, etc.

Do you have the code available anywhere? I'm working on the same thing to learn how to utilize MCP, I'd love to see how someone else went about it.

this will break, kill your computer and probably result in loss of life. Just saying. :)

That said, here's a gist: https://gist.github.com/vessenes/ec43b76965eed1b36b3467c598b...

That sounds like v1 was "tool calls llm", while v2 is "llm calls tool"?

The fact that the tool call is via mcp and not in-process function call seems to be an implementation detail?

first sentence sounds right to me.

“Implementation detail” is doing a lot of work in the second sentence, though. There are whole startups like langchain that were trying to build out a reasonable agent framework integrated in such a way that the LLMs can drive. MCP makes that really easy — LLM training just has to happen once, against MCP spec, and I get client and LLM support for an iterative tool use scenario right in the LLM.

So is the MCP server acting like a middleman between the llm and the application you want to control?

Like, could I give the MCP server the ability to say exec Unix code on my machine and then tell the LLM "here's the MCP server, this function can execute Unix code and get back the response".

Then I can tell the LLM, "create an application using the MCP server that will listen to a GitHub webhook and git pull when the webhook hits and have it running" then the LLM would generate the commands necessary to do that and run them through the MCP server which just executed the Unix code. And viola?

I've gotten an llm to create files and run system commands for me.

Is that the most barebones application?

> What is there to standardize?

At a high level, the request format and endpoints. Instead of needing to write a bespoke connector for every type of context that matches their preferred API standards, I just tell my client that the server exists and the standard takes care of the rest.

Do you have similar doubts about something like gRPC?

> This looks like micro services crossed with AI.

Seems like a cynical take with no substance to me. What about a standard request protocol implies anything about separation of concerns, scaling, etc?

> At a high level, the request format and endpoints.

I think we fundamentally disagree on what "request format" means in context of a large language model.

Because it's not a request format for LLMs, it's a request format for client software that is instrumenting LLMs. If you make a connector to say HomeAssistant to turn on/off your lights you're exposing a tool definition which is really just a JSON schema. The agent will present that tool to the LLM as one it's allowed to use, validate that the LLM matched your change_light_state tool schema and send off the appropriate API call to your server.

The spec is genuinely a hot fucking mess that looks like a hobby project by an overeager junior dev but conceptually it's just a set of JSON schemas to represent common LLM things (prompts, tools, files) and some verbs.

The useful content of the spec is literally just https://github.com/modelcontextprotocol/specification/blob/m... and even then it's a bit much.

Literally every protocol ever written is “clever heuristics over plain-ass {bits|bytes|text|etc}”

I would think of MCP as a "plugin" for AI.

Right now your typical interaction in chat is limited with some exceptions of out of box tooling that most current platforms provide: file attachment, web search, etc.

MCP is a way to extend this toolbox, but the cooler thing is AI will be able to determine _at inference time_ what tools to use to fulfill the user's prompt.

Hope this helped!

More like a "plugin system" than a "plugin"

Well, you should check again, because it hasn't been text to text for a while. There are multimodal models now.

If we want to get pedantic, in context of practical transformer models it has never been text to text. It has always been tokens to tokens. The tokens can represent anything. "multimodal" is a marketing term.

You could say the same thing about almost any protocol, e.g. HTTP, which runs on arbitrary streams of bytes over TCP; and the headers, methods and status codes are just illusions on top of that.

Reply on news.ycombinator.com