4 ms·

so we no longer need langchain and stuff like that, that's a win. But MCP also feels a bit overrated:https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit https:

by fsndz 2y ago

so we no longer need langchain and stuff like that, that's a win. But MCP also feels a bit overrated:https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit

esafak 2y ago
I could not find the actual criticism in that article. What's the problem with MCP again? It's the first standard for agents.
- fsndz 2y ago
  the problem of agents is not the lack of standards, but reliability (reliability of tool use and reliability of outcomes). MCP does not solve any of that.
  - esafak 2y ago
    That is not mentioned in the article. I am just becoming familiar with MCP myself so I suggest raising the issue: https://github.com/orgs/modelcontextprotocol/discussions https://github.com/orgs/modelcontextprotocol/discussions
  - paulgb 2y ago
    Standards might not have been _the_ problem, but they were _a_ problem. Before MCP I couldn't distribute a tool call that could be configured by end-users to be used with multiple mainstream clients.
  - mindwok 2y ago
    This is just moving the goalposts, MCP is not supposed to solve every problem with agents. It's meant to make it easier to provide easier, standardised ways for LLMs to interact with external tools, which it has done. Reliability is a completely different problem.
- mkagenius 2y ago
  http endpoint + function calling can do what MCP do, this extra bad named layer is just jargon festish
  - knowaveragejoe 2y ago
    Okay, but we should have a standard around that, right? Something like... a protocol?
paulgb 2y ago
That article seems to miss the point by being incurious about _why_ there is hype around MCP instead of LangChain, LangGrah, SmolAgents, LlamaIndex, etc. We've had tool call frameworks before, but we haven't had a way of making tools that our clients actually talked to. There was no way to build tools that other people could download and run locally without getting them to switch to a client that baked those tools in. It's like the difference between static linking and dynamic linking, but for tool calls.
- rvz 2y ago
  > That article seems to miss the point by being incurious about _why_ there is hype around MCP instead of LangChain, LangGrah, SmolAgents, LlamaIndex, etc. The VCs that were invested in AI companies (like Cursor) would of course need to hype something up like MCPs to get us to build them as little of those tools did not exist. Cursor already makes $100M+. So why not get behind and integrate this chosen standard to make even more money with more MCP servers. The last ingredient is to hype it all up on the internet to get everyone building. A win for the VCs regardless even though it was suspiciously orchestrated as soon as Cursor integrated it.
  - vessenes 2y ago
    I too feel it's bad that companies take VC money and build open standards which let me build faster and target more providers. Seriously, what? I struggle to understand the mindset of someone frequenting HN who can say unironically that "getting everyone building" is a bad outcome. I'd like some more of that getting everyone building please.
  - leonidasv 2y ago
    MCPs aren't specific to Cursor. Rather, they enable any IDE to become a Cursor competitor. Example: JetBrains released an MCP server plugin for their IDEs recently and it enables Claude Desktop to seamlessly use the IDE for reading and writing files and even compiling or running tests against it. And that's just one example; there are MCP servers for anything from VSCode to Emacs already. That means almost anyone can now use LLMs to generate code in their IDE of choice, just as they would do with Cursor. In fact, MCPs are posing a threat to many startups, especially the "wrapper" ones.
_2d30 2y ago
I feel like that article doesn't really live up to its title. At the end, its basic point is that MCP isn't a magic bullet (I don't think anyone claimed it was?) and that it has a lot of hype. It also makes it clear why MCP is good (ie don't need to rely on LangChain). Feels like its title should be "Why MCP is a Good Step but Doesn't Solve Agents" or something. But then, it wouldn't enable the millenial urge to use "shit".
rvz 2y ago
> But MCP also feels a bit overrated: VCs invested in AI and agentic companies needed a way to get you guys to accelerate agents this year. So why not "create" artificial hype for MCPs on the internet, since there were little to no MCP servers for LLMs to use despite it being several months old (November 2024) until Cursor integrated it. This is the true reason why you see them screaming about MCPs everywhere.
- fkyoureadthedoc 2y ago
  So the main criticism is a borderline conspiracy theory about VC's creating artificial hype for it?
  - AtomBalm 2y ago
    Hype isn’t free. Maybe the benefit is mutual, but I can’t tell how Anthropic gets paid. Anthropic subsidizes an open standard, but proprietary extensions later emerge that lock you into servers from their marketplace or something? I need a sociopath to help me understand this.
    - kschrader 2y ago
      The Anthropic models are running underneath everything (Claude Code, Windsurf, Cursor, etc). Whenever someone is using MCP they (in the generalized case, until now) ultimately end up using Anthropic as their LLM and Anthropic gets paid whenever someone does that.
      - varelaseb 2y ago
        This is literally not true. You can leverage MCP using any model. Even some of the IDEs you mention let you leverage MCP using many model providers.
    - knowaveragejoe 2y ago
      There's already like a half dozen such "marketplaces" and they all ultimately point to open source repos. If the goal was to lock people in, they did a bad job of it.
taude 2y ago
there's a reason there's MCP plugins for LangChain. Some companies will need massively customized workflows that LangChain is appropriate for, where it only needs to dig into a couple potentially publically accessed MCPS for things. I could see a future where companies have their developer portal where now they have their APIs document, the pretty in swagger, the samples, etc, but they'll have a MCP endpoint (potentially), where they're safely exposing the data to an LLM. Your langchain node step to to get context, could call out to some of these hosted/shared mcps where you do standard stuff, like post to a Slack channel, grab some data from a SFDC instance, etc....

by fsndz 2y ago

esafak 2y ago

I could not find the actual criticism in that article. What's the problem with MCP again? It's the first standard for agents.

fsndz 2y ago
the problem of agents is not the lack of standards, but reliability (reliability of tool use and reliability of outcomes). MCP does not solve any of that.
- esafak 2y ago
  That is not mentioned in the article. I am just becoming familiar with MCP myself so I suggest raising the issue: https://github.com/orgs/modelcontextprotocol/discussions https://github.com/orgs/modelcontextprotocol/discussions
- paulgb 2y ago
  Standards might not have been _the_ problem, but they were _a_ problem. Before MCP I couldn't distribute a tool call that could be configured by end-users to be used with multiple mainstream clients.
- mindwok 2y ago
  This is just moving the goalposts, MCP is not supposed to solve every problem with agents. It's meant to make it easier to provide easier, standardised ways for LLMs to interact with external tools, which it has done. Reliability is a completely different problem.
mkagenius 2y ago
http endpoint + function calling can do what MCP do, this extra bad named layer is just jargon festish
- knowaveragejoe 2y ago
  Okay, but we should have a standard around that, right? Something like... a protocol?

paulgb 2y ago

That article seems to miss the point by being incurious about _why_ there is hype around MCP instead of LangChain, LangGrah, SmolAgents, LlamaIndex, etc. We've had tool call frameworks before, but we haven't had a way of making tools that our clients actually talked to. There was no way to build tools that other people could download and run locally without getting them to switch to a client that baked those tools in. It's like the difference between static linking and dynamic linking, but for tool calls.

rvz 2y ago
> That article seems to miss the point by being incurious about _why_ there is hype around MCP instead of LangChain, LangGrah, SmolAgents, LlamaIndex, etc. The VCs that were invested in AI companies (like Cursor) would of course need to hype something up like MCPs to get us to build them as little of those tools did not exist. Cursor already makes $100M+. So why not get behind and integrate this chosen standard to make even more money with more MCP servers. The last ingredient is to hype it all up on the internet to get everyone building. A win for the VCs regardless even though it was suspiciously orchestrated as soon as Cursor integrated it.
- vessenes 2y ago
  I too feel it's bad that companies take VC money and build open standards which let me build faster and target more providers. Seriously, what? I struggle to understand the mindset of someone frequenting HN who can say unironically that "getting everyone building" is a bad outcome. I'd like some more of that getting everyone building please.
- leonidasv 2y ago
  MCPs aren't specific to Cursor. Rather, they enable any IDE to become a Cursor competitor. Example: JetBrains released an MCP server plugin for their IDEs recently and it enables Claude Desktop to seamlessly use the IDE for reading and writing files and even compiling or running tests against it. And that's just one example; there are MCP servers for anything from VSCode to Emacs already. That means almost anyone can now use LLMs to generate code in their IDE of choice, just as they would do with Cursor. In fact, MCPs are posing a threat to many startups, especially the "wrapper" ones.

_2d30 2y ago

I feel like that article doesn't really live up to its title. At the end, its basic point is that MCP isn't a magic bullet (I don't think anyone claimed it was?) and that it has a lot of hype. It also makes it clear why MCP is good (ie don't need to rely on LangChain). Feels like its title should be "Why MCP is a Good Step but Doesn't Solve Agents" or something. But then, it wouldn't enable the millenial urge to use "shit".

rvz 2y ago

> But MCP also feels a bit overrated: VCs invested in AI and agentic companies needed a way to get you guys to accelerate agents this year. So why not "create" artificial hype for MCPs on the internet, since there were little to no MCP servers for LLMs to use despite it being several months old (November 2024) until Cursor integrated it. This is the true reason why you see them screaming about MCPs everywhere.

fkyoureadthedoc 2y ago
So the main criticism is a borderline conspiracy theory about VC's creating artificial hype for it?
- AtomBalm 2y ago
  Hype isn’t free. Maybe the benefit is mutual, but I can’t tell how Anthropic gets paid. Anthropic subsidizes an open standard, but proprietary extensions later emerge that lock you into servers from their marketplace or something? I need a sociopath to help me understand this.
  - kschrader 2y ago
    The Anthropic models are running underneath everything (Claude Code, Windsurf, Cursor, etc). Whenever someone is using MCP they (in the generalized case, until now) ultimately end up using Anthropic as their LLM and Anthropic gets paid whenever someone does that.
    - varelaseb 2y ago
      This is literally not true. You can leverage MCP using any model. Even some of the IDEs you mention let you leverage MCP using many model providers.
  - knowaveragejoe 2y ago
    There's already like a half dozen such "marketplaces" and they all ultimately point to open source repos. If the goal was to lock people in, they did a bad job of it.

taude 2y ago

there's a reason there's MCP plugins for LangChain. Some companies will need massively customized workflows that LangChain is appropriate for, where it only needs to dig into a couple potentially publically accessed MCPS for things. I could see a future where companies have their developer portal where now they have their APIs document, the pretty in swagger, the samples, etc, but they'll have a MCP endpoint (potentially), where they're safely exposing the data to an LLM. Your langchain node step to to get context, could call out to some of these hosted/shared mcps where you do standard stuff, like post to a Slack channel, grab some data from a SFDC instance, etc....