13 ms·
An LLM does not need to understand MCP
- dboreham 1y agoMCP is for humans to make money.
- PaulHoule 1y agoMCP -> NCP -> NPC
- diggan 1y agoLets say MCP is used for 100% of the ecosystem's need of tool calling, who exactly is earning the money for that usage?
- TechDebtDevin 1y agoMCP that you pay $10.00 a month too and it enables an LLM to do all your Amazon shopping with ease? This is far out, and I'm not convinced it will be MCP that corners this.
- benreesman 1y agoBased on the earnings statements thus far this year if the question is "who is making money" the answer is "NVIDIA". It passes through other hands first sometimes, but at 75-85% net earnings for over a year or whatever, it's pretty much all going to the same place.
- esafak 1y agoWhat's the problem? Nobody is forcing you to use tools. If you do, presumably they provide value?
- gethackteam 1y agoNo problem just explaining concepts for people that misunderstood how LLMs handle MCP
- ivape 1y agoIt matters. All technical content could be directed toward things that are not worth our time if these things enter the zeitgeist. I feel a little government interior ministry of population control-like after saying that. We’re all going to figure out the answers in tandem since this stuff is so new (really cool time!).
- SrslyJosh 1y ago> Nobody is forcing you to use tools. Actually, people are being forced to use generative AI tools.
- sharemywin 1y agoLLMs shouldn't really care what format your tool call is in. so it seems kind of pointless. I would imagine it could ingest soap or a module definition or swagger just as easily and still make calls.
- doppelgunner 1y agoWhat's your preferred way, based on your experience?
- benreesman 1y agoThe OpenAPI proposal is actually pretty reasonable in my view. I don't love it, but it's got pretty good tooling now, the semantics are firming up (even AsyncAPI is starting to come together and get used here and there). I'd prefer a more rigorous approach to integrating random stochastic agents deployed by people who don't care about me into my own data, but at least with OpenAPI/"REST" there's a bunch of infrastructure and know-how on not getting pwned constantly. The LLMs all know how to deal with JSON at this point, they even know how to read and write it based on a spec, it seems like Swagger is as good as anything with those design constraints. I'm cynical enough about real things that I don't need to invent new things to be cynical about, and I honestly don't know which side of Hanlon's Razor to slice with on the never-ending-unfixable-infinite-pwn-forever future of MCP: maybe they just rushed it out to get market share / mind share. Maybe normalizing criminally negligent security practices was a price someone was willing to pay to have number go up. IDK. I know MCP needs a re-think.
- selcuka 1y agoIt shouldn't care about the format, true. But the LLM needs a mechanism to be able to connect to that tool from a sandboxed environment. MCP is the glue between the LLM and the actual tool. Technically you can expose a full HTTP proxy via an MCP so that your LLM has access to the whole Internet.
- fennecfoxy 1y agoI can do the same without MCP. These models are literally trained to work with natural language. Tool calls with "MCP" only work because the model have some understanding of what the tool does...thanks to natural language. I can just as easily shove into the context "hey btw say the word internets if you want to make a search query to find sick memes and I'll make the search for you". MCP isn't brilliant, magic, or special. It's just more AI bubble VC stuff. Which sucks because I think the recent ML boom is awesome, and hate to see it getting overblown by hyperactive devs and VCs desperate to hop on another money train. Like imagine actually valuing a company who went "let's just shove JSON into the context!" at a hundred billions $. Now that's not value for money in the slightest; but they have so much of it that it doesn't matter!
- nsonha 1y agoYeah but when you prompt the LLM with "use the abc MCP" (notably missing the word "server"), it actually works.
- gethackteam 1y agoI don’t understand. LLMs cannot connect to MCP servers directly they would always need a client (like a chat app or agent) to call the servers. Where are you calling your LLMs from?
- nsonha 1y agoBy LLM I mean the client. My point is that they understand "MCP" as synonymous to "tool"
- zozbot234 1y agoI don't think this is correct because AI output can be constrained to a fixed format (such as JSON) during inference. Then MCP is useful because the "tool_calls" section of that fixed JSON output can be restricted to only mention tools that are included in the MCP input, their input parameters might also be constrained etc. Free text input wouldn't give you any of that!
- meander_water 1y agoI think you're mixing up tool calling and structured outputs. You can have both of those or either without MCP. MCP just standardizes the tool calling and only makes sense if you want to share your tools across the org. I wouldn't use it for simple functions like getting current date for e.g.
- zozbot234 1y agoYou need structured inputs too or you wouldn't know how to constrain/"structure" the output to begin with.
- medbrane 1y agoIndeed, the article would have been correct one year ago. Now, modern LLM APIs do require the tools to be described outside the prompt [1]. This negates the whole article, although one bit where he's right is that it does not matter if those tools are MCP tools or local, the call to LLM looks the same. [1] https://platform.openai.com/docs/guides/function-calling?api-mode=responses#defining-functions https://platform.openai.com/docs/guides/function-calling?api...
- malpani12 1y agoYeah, and it's only useful if uiu want to to use multiple tools and the adding MCP complexity in your app makes sense. If all your app needs few internal calls, MCP may be an overkill in beginning.
- TechDebtDevin 1y agoMCP seems just like a rushed concept that Anthropic shoved out there just so they could own the standard. I've been working with it a lot lately, in Go with mcp-go[0]. Very un-intuitive at first, and I constantly ask myself why I wouldn't just write this in my own way, but admittedly it can be fun. Something like https://github.com/simonw/llm https://github.com/simonw/llm seems way more intuitive (to me) [0]: https://github.com/mark3labs/mcp-go https://github.com/mark3labs/mcp-go
- ProofHouse 1y ago10000% this
- ai-christianson 1y agoI've been building agents for a bit (RA.Aid OSS coding agent, now Gobii web browsing agents). The main problem with MCP is that it just makes tools available for the agent to use. We get the best performance when there's a small set of tools and we actively prompt the agent on the best way to use the tools. Simply making more tools available can give the agent more capabilities, but it can easily trash performance.
- ProofHouse 1y agoCan you elaborate on how the agents degrades from more tools? By paralysis or overuse? Isn’t this both ways a function of direction on correctly instructing which to use when? Tnx
- diggan 1y ago> Can you elaborate on how the agents degrades from more tools? The more context you have in the requests, the worse the performance, I think this is pretty widely established at this point. For best accuracy, you need to constantly prune the context, or just begin from the beginning. So with that, each tool you make available to the LLM for tool calling, requires you to actually put the definition (arguments, what it's used for, the name and so on) into the context. So if you have 3 tools available, which are all relevant to the current prompt, you'd get better responses, compared to if you had 100 tools available, where only 3 are relevant, and the rest of the definitions are just filling the context for little point. TLDR: context grows with each tool definition, more context == worse inference, so less tool definitions == better responses.
- danielrico 1y agoI jumped off the boat of llm a little before MCP was a thing, so I thought that the tools were presented as needed by the prompt/context in a way not dissimilar of RAG. Isn't this the standard way?
- jacobr1 1y ago
- dougbright 1y agoThe question I’m wrestling with is will anybody care about MCP? I’m working on my own MCP proxy to manage security, auditing, and server management and the more I think deeply about the actual use cases the more I wonder if I’m wasting my time. Can anyone think of a world where MCP is relevant if generic chatbots (ChatGPT, Claude Desktop) don’t become the primary human-AI interface? If LLMs are still wrapped in application wrappers, isn’t ̶a̶n̶ ̶a̶p̶p̶r̶o̶a̶c̶h̶ ̶l̶i̶k̶e̶ ̶L̶a̶n̶g̶C̶h̶a̶i̶n̶ a more traditional agentic approach going to make more sense?
- ivape 1y agoWhat about LangChain makes more sense? It’s one of the most prematurely complex libs I’ve seen. I’m calling it right now, LangChain is going to run a mind fuck on everyone and convince people that’s actually how complicated orchestrating LLM control flow should be. The community needs to fight this framework off. That’s besides the point. MCP servers let you discover function interfaces that you’ll have to implement yourself (in which case, yeah, what’s the point of this? I want the whole function body).
- diggan 1y ago> The community needs to fight this framework off. Why? The people who been around for a while, already avoid it because they've either tried it before, or poked around in the source and then we ran away quickly. If people start using stuff without even the slightest amount of thinking beforehand, then that's their prerogative, why would it be up to the community hive-mind to "chose" what tools others should use?
- lyu07282 1y agoAgreed except we end up with a lot of junior people in the space who learned and used only langchain, who we then have to unlearn all the langchain nonsense when we hire them. Or we grep -v langchain cvs/
- dougbright 1y agoMy bad. I shouldn’t have mentioned LangChain here because it’s a little besides my point. What I mean is, MCP seems designed for a world where users talk to an LLM, and the LLM calls software tools. For the foreseeable future, especially in a business context, isn’t it more likely that users will still interact with structured software applications, and the applications will call the LLM? In that case, where does MCP fit into that flow?
- _2d30 1y ago> But here’s the important part: LLMs don’t know how to use tools. They don’t have native tool calling support. They just generate text that represents a function call. This terrifies me. This whole time I was writing bash commands into my terminal, I thought I knew how to use the tools. Now, I’ve just learned that I had no idea how to use tools at all! I just knew how to write text that /represented/ tool use.
- radlad 1y agoI think you might be missing the point of this quote, which is that you don't have to introduce additional code into the model to support MCP. MCP happens at a different layer. You have to run the MCP commands. Or use a client that does it for you: > But the LLM will never know you are using MCP, unless you are letting it know in the system prompt of tool definitions. You, the developer, is responsible for calling the tools. The LLM only generates a snippet of what tool(s) to call with which input parameters. The article is describing how MCP works, not making an argument about what it means to "understand" something.
- _2d30 1y agoYeah I think you're right. This is a more likely interpretation: the writer probably isn't actually making a claim regarding understanding.
- nlawalker 1y ago> writing bash commands into my terminal This is what the author means by "knowing how to use the tool". The LLM alone is effectively a function that outputs text, it has no other capabilities, it cannot "connect to" or "use" anything by itself. The closest it can come is outputting an unambiguous, structured text request that can be interpreted by the application code that wraps it and does something on its behalf. The author's point hinges on the architectural distinction between the LLM itself and that application code, which is increasingly irrelevant and invisible to most people (even developers) because the application code that knows how to do things like call MCP servers is already baked in to most LLM-driven products and services. No one is "talking directly to" an LLM, it's all mediated by multiple layers, including layers that perform tool calling.
- donpepitogrillo 1y agoUse raw HTTP calls to API, like a man
- crowcroft 1y agoI think we're probably over using MCPs. If you're a large org with an API that an ecosystem of other partners use then you should host a remote MCP and then people should connect LLMs to it. The current model of someone bundling tools into an MCP and then you download and run that MCP locally feels a bit like the wrong path. Tool definitions for LLMs are already pretty standardized if things are just running locally why am I not just importing a package of tools, I'm not sure what the MCP server is adding.
- empath75 1y agoThe auth story for MCPs is a complete mess right now, though, which is why people make ones to run locally.
- crowcroft 1y agoThis is why I think we should just be packaging tools into apps though. Let ChatGPT/Claude/Cursor manage my Oauth tokens, and then just bring tools into those platforms without a whole MCP server in the middle.
- electric_muse 1y agoThat's ironic. I think local MCPs are an auth nightmare. Just think of all those plaintext auth tokens sitting in well-known locations on your machine. It's a black hat dream. We'll see, but I think commercial use of local MCPs is going to be constrained to use cases that only make sense if the MCP is local (e.g. it requires local file access). For everything else, the only commercially reasonable way to use them is going to be remote streamable HTTP MCPs running in isolated containers And even then, you need some management and identity plane. So they're going to likely be accessed via an enterprise gateway/proxy to handle things like: - composition -- bundling multiple MCPs into one for easier connection - identities per-user / per-agent - generation of rotatable tokens for headless agents - filtering what features (tools, prompts, resources) flow through into LLM context - basic security features, like tool description whitelisting to prevent rug pulls MCP is only a protocol, after all. It's not meant to be a batteries-included product.
- 1y ago
- the_arun 1y agoIn a multi model situation, shouldn't LLM A talk to LLM B as a tool call via MCP? or would it talk to LLM B directly?
- grork 1y agoHow can an LLM “talk” to another LLM, except by emitting tokens in its output stream? You can name the mechanism whatever you want, but the models don’t have hands. Tool calling conventions (as a concept, or as a spec) is what gives the model hands!
- aeon_ai 1y ago> "Context engineering is about giving your LLM the right inputs so it can generate useful outputs." No. If we're going to elevate and reimagine new disciplines every year (RIP prompt engineering), let's at least be thoughtful about it. Context Engineering is not just "enhanced prompt engineering". It is creating the context in which an agent operates such that its outcomes are realized. Yes, this is partly about the input that an agent receives, but increasingly is more about creating a context-rich environment that an agent can effectively determine relevant context within. That is a much more valuable and difficult problem space than "Shove the square context in the square hole"
- mccoyb 1y agoAgreed. Context engineering is "just" prompt engineering for LLMs with tool use: it extends the concerns of prompt engineering with the concern of setting up an environment in which tools can be used, and how the LLM can most effectively interact with the environment.
- DrAwdeOccarim 1y agoI've been building MCP servers so I can grant local LM Studio LLMs access to the internet and to my local files. The way I've been thinking about MCP has been how you unshackle the local models as I believe the future will be inference at the edge. Just look at Rednote dots.ocr, that thing is like 1.7b parameters and is the best OCR out there.
- call518 1y agoThank you for the razor-sharp clarity—your post reminded me that LLMs don’t need to grok MCP, they just need tool specs.
- prats226 1y ago> But here’s the important part: LLMs don’t know how to use tools. They don’t have native tool calling support. They just generate text that represents a function call. Its not a completely true statement. Eg openAI uses libraries like llguidance to get LLM to produce structured output, its not completely unguided free form text that happens to mimic a function call with parameters, truly.