Comment by saberience
3 days ago
Huge variety of problems with this for mid-market or enterprise use. This is basically a toy right now and can’t be used for solving repeatable, valuable problems for actual businesses, ie: stuff that matters.
One: dependence on langchain.
Two: Security? Observability?
Three: You have never asked yourself, why would someone want to connect an LLM to infinite random mcp servers. The vast majority (of mcp tools and servers) are insecure, vibe coded, basically terrible.
Four: There needs to be way more focus on quality versus quantity. It’s easy to connect LLMs to MCP servers, it’s not a problem companies are willing to spend much money on, the issue is ensuring LLMs call the right tools 98%+ of the time with the right parameters.
Five: There are tons and tons of existing projects for connecting LLMs to 1000s of MCP servers, it’s not a novel project, has no technical moat, and importantly, doesn’t solve a super valuable problem.
The better question to ask or problem to solve is this, given a high value problem, how do you get high values of accurate tool use, first time, while providing security and protection against side effects, jail breaking, random issues etc.
Most companies using “mcp” have a model which is using one or two tools (max) at a time and struggling making it work consistently. Giving them a meta tool to connect to 1000s of (mostly useless) tools isn’t helpful and won’t be taken seriously.
Hey, thanks for your detailed feedback, it's helpful to be challenged. Here are some quick thoughts:
One: We've heard similar feedback on Langchain dependency. We also heard it is still widely used in enterprise settings despite its limitations. We're actively exploring alternatives, but it is a pretty crowded space and we could not find the best alternative yet. I'm curious: is there a specific solution you'd recommend? Shall we have our own LLM layer ?
Two: Agreed on observability client-side, improvements are on our roadmap, though currently prioritized lower based on user needs. Regarding security, we manage server-side risks via sandboxes, tool restrictions, and upcoming access control features. Preventing tool poisoning client-side is something we'll look into further. You have any other specific suggestions client side ?
Three: The "infinite server" scenario is not the main focus on the library, I am sorry if that is how is sounded. It is more of an interesting solution to an interesting problem that we wanted to share.
Four: Totally agree on prioritizing quality over quantity. mcp-use emphasizes flexibility and ease of integration, not necessarily connecting to numerous servers. Reliability is a server-client joint effort, when we work with companies this is one of our main focuses.
Five: While similar solutions exist, we've found our approach resonates well with users based on adoption and feedback. That said, this is not the end of the road, we are working and talking with many companies and solving many of the issues you mentioned, most are not so easy to integrate in the library and we offer only as part of our cloud offering.
Thanks again for challenging our thinking! And please if you have inputs it'd be great to have them
Why is dependence on LangChain an issue?
Not that I disagree necessarily, just wondering if there's a consensus that LangChain is too opinionated/bloated/whatever for real industry applications, or if there's some other reason.
Not original commenter here, and not by first hand experience. BUT. I got this kind of feedback from some communities, and I wanted to understand what companies think of this, I asked some dev that works in a company that sells software to enterprise he says that enterprise still use langchain mostly and they are fine with it. On a personal level I agree with the feedback in that langchain has some drawbacks, but at the same time it's a great way to get started.