3 ms·
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 proto
by bob1029 2y ago
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.
- nlarew 2y ago> 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?
- bob1029 2y ago> 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.
- Spivak 2y agoBecause 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/main/schema/2025-03-26/schema.json https://github.com/modelcontextprotocol/specification/blob/m... and even then it's a bit much.
- vessenes 2y agoIf 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.
- digdugdirk 2y agoDo 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.
- vessenes 2y agothis 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/ec43b76965eed1b36b3467c598bcc131 https://gist.github.com/vessenes/ec43b76965eed1b36b3467c598b...
- senko 2y agoThat 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?
- vessenes 2y agofirst 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.
- deleted 2y ago[deleted]
- analyte123 2y agoYou 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.
- ripped_britches 2y agoLiterally every protocol ever written is “clever heuristics over plain-ass {bits|bytes|text|etc}”
- oefnak 2y agoWell, you should check again, because it hasn't been text to text for a while. There are multimodal models now.
- bob1029 2y agoIf 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.
- orangebread 2y agoI 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!
- Ey7NFZ3P0nzAe 2y agoMore like a "plugin system" than a "plugin"