3 ms·
This is a really shallow dismissal, and I say that as someone who is outspokenly critical of MCP [0]. As you yourself say, the context is the text that is fed
by lolinder 1y ago
This is a really shallow dismissal, and I say that as someone who is outspokenly critical of MCP [0].
As you yourself say, the context is the text that is fed as input at runtime to an LLM. This text could just always come from the user as a prompt, but that's a pretty lousy interface to try to cram everything that you might want the model to know about, and it puts the onus entirely on the user to figure out what might be relevant context. The premise of the Model Context Protocol (MCP) is overall sound: how do we give the "Model" access to load arbitrary details into "Context" from many different sources?
This is a real problem worth solving and it has everything to do with the technical meaning of the word "context" in this context. I'm not sure why you dismiss it so abruptly.
[0] https://news.ycombinator.com/item?id=43949503 https://news.ycombinator.com/item?id=43949503
- TZubiri 1y agoBut that's not what MCP does. It is a tool created by anthropic ( 2nd most used LLM) to provide portabiliry and vendor neutrality between different LLMs. It's like terraform for LLMs. Also providing data through function calls/tool use is not context, you are overloading the term. Context is LLM context, if you fetch from a db it's something else
- lolinder 1y ago> But that's not what MCP does. It is a tool created by anthropic ( 2nd most used LLM) to provide portabiliry and vendor neutrality between different LLMs. It's like terraform for LLMs. Given that your only contributions in this thread are to acknowledge your ignorance of MCP [0] and to post the summary dismissal upthread that shows your ignorance of it, it would probably behoove you to actually learn about MCP more before confidently making assertions about it. Suffice it to say that this is inaccurate and others have already explained in your "WTF is it" thread what MCP actually is. > Also providing data through function calls/tool use is not context, you are overloading the term. Context is LLM context, if you fetch from a db it's something else If you believe this then you don't understand how tool use is implemented. It's literally accomplished by injecting a tool's response into the context [1]. As a general life tip: most pedants are wrong most of the time. If you find yourself being pedantic, take a few steps back and double check that you're not just wrong. [0] https://news.ycombinator.com/item?id=44011320 https://news.ycombinator.com/item?id=44011320 [1] https://platform.openai.com/docs/guides/function-calling https://platform.openai.com/docs/guides/function-calling
- TZubiri 1y agoIf you believe this then you don't understand how tool use is implemented. It's literally accomplished by injecting a tool's response into the context [1]. I was doing tool use before chatgpt released an official API for function calls. You literally give ChatGPT API specs and ask it to generate call parameters. The API is fed into the LLM as context, the response is part of the output. Whether you pass that output through another layer of LLM is trivial. And even if you do, the "context" in that case would be only the response, not the whole database. You are confusing even yourself, you accepting the overloading of the word 'context' (pushed by a company for commercial purposes) and you are now unable to distinguish between LLM context in terms of tokens, an external data source, and a response fetched by the tool. It's not that I am ignorant of what Anhtropic claims Context means, I'm contesting it. If Microsoft releases a new product and claims that Intelligence is the parameters of their Microsoft Product, then it pays to be a bit cynical instead of parroting whatever they say like some unpaid adman
- lolinder 1y agoI couldn't care less about Anthropic or MCP—as I noted, I'm a critic of MCP—but pedants bug me quite a bit especially when they're wrong. > The API is fed into the LLM as context, the response is part of the output. So you implement tool use by feeding an API into the LLM as context in order to get it to produce call parameters. Got it. > Whether you pass that output through another layer of LLM is trivial. And even if you do, the "context" in that case would be only the response So the output of the tool when called with those parameters can be fed back into the LLM as further context. Got it. Given the above, it seems that we agree that tool use is implemented entirely by giving selected bits of context to the model. With that in mind, if one were to design a protocol that makes tool use plug-and-play instead of something that has to be coded by hand for each tool—a protocol designed to allow a model to discover tool APIs that it might want to bring into context and then use those APIs to bring their outputs into context—it would be reasonable to call said protocol the Model Context Protocol, because it's all about getting specific bits of Context into a Model. I'm not sure why the word "context" is the hill you decided to die on here when there is so much else to pick on with MCP, but it's time to get off the hill.