alt Hacker NewsShow HN: Mcp-use – Connect any LLM to any MCP
Hey Pietro and Luigi here, we are the authors of mcp-use (https://github.com/mcp-use/mcp-use).
When the first MCP servers came out we were very excited about the technology, but as soon as we wanted to get our hands dirty, we found out that MCP could be used only through Claude Desktop or Cursor. As engineers, we did not like that. MCP seemed like something you wanted to use to build products and applications yourself, not something to hide behind a closed source application.
So we approached the SDK but were pretty dissatisfied with the developer experience (double async loops, lots of boilerplate). We decided to write mcp-use to make our lives easier.
mcp-use lets you connect any LLM to any MCP server in just 6 lines of code. We provide a high level abstraction over the official MCP SDK that makes your life easier and supports all the functionalities of the protocol.
Demo video here: https://www.youtube.com/watch?v=nL_B6LZAsp4.
The key abstractions we provide are called MCPClient and MCPAgent.
MCPClient takes in a set of server configurations, automatically detects the transport type and creates a background task which handles the stream from/to the server.
MCPAgent is a combination of the MCPClient, an LLM, and a custom system prompt. It consumes the MCP client by transforming the tools, resources and prompts into model agnostic tools that can be called by the LLM.
The library also contains some cool utilities:
- secure sandboxed execution of MCP servers (we know the protocol doesn't shine for security)
- meta-tools that allow the agent to search over available servers and tools (to avoid context flooding) and connect dynamically to the server it needs (you could create the omnipotent agent with this).
Some cool things we did with this: - write an agent that can use a browser and create/read linear tickets updated with latest information on the internet
- write an agent that has access to the metrics of our company to automatically create weekly reports.
- I connected an agent to an IKEA curtain I hacked an MCP on to adapt the lighting of my room from images of the lighting situation.
- recreated am open source claude code like CLI, with full MCP capability but with custom models and BYOK (https://github.com/mcp-use/mcp-use-cli).
We recently crossed 100,000 download and we are used by many organizations, including NASA!
We’d love to hear what you think of it, most importantly how we can improve it! We are happy to answer any questions and look forward to your comments.
Comments
I get the client part, great job!
However, the agent is really just a wrapper of Langchain AgentExecutor. This doesn't seem like something someone would want to put into production.
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.
Great idea! Definitely going to use it. What are some good reasons to prefer this over fastmcp clients? https://gofastmcp.com/clients/client
For what it’s worth, several months ago, in Langroid (an agent framework that works with any LLM) we added an adaptor using FastMCP that translates between Langroid’s Tools and MCP tools, so effectively it’s a way to connect any LLM to any MCP server.
Https://github.com/langroid/langroid
MCP integration:
I have used mcp-use to write some demo functionality and it is very easy to use and works great!
> MCP-Use supports running MCP servers in a sandboxed environment using E2B's cloud infrastructure.
If you want to support a local and privacy friendly sandboxed environment for code execution, you may consider something I have built, Coderunner - https://github.com/instavm/coderunner - it uses Apple's native container for hosting a jupyter server and a headless browser.
How does the sandboxing work? Is it cross platform? Options for filesystem/netork?
Introduced the tool at Porsche last week. Looks like there might be a big corporate partnership coming up
neat idea and exec. With the # of MCPs exploding, I assume there will be different MCPs offering similar services, and selecting the "right" one will require more time for the devs. I see interesting implications in the Server Manager component that will hide the complexity under the hood (for practical and security reasons). Good job.
Do you do anything to deal with the model performance degradation caused by having too many MCP tools? Would be cool to see a smart MCP router added here
What is really interesting in this article is that no where in either the github link presented nor on his web site, mcp-use.com, does he actually explain what an "MCP" server is, what it might be used for, the benefits of doing this. It seems he is so far in the weeds with this that it was an after thought to describe what any of this means or might be useful for.
Not sure what is going on, but I see a lot of 1-karma-point HN users hyping this.
I'm not sure how this relates to the comment you replied to?
Since you're in the current YC batch, why is this a Show HN instead of a Launch HN?
[stub]
[explained at https://news.ycombinator.com/item?id=44752814]
Hey, this is really cool. But why should I use this and not the official SDK?
The prod-readiness concerns are fair, but mcp-use fills a real gap in the MCP stack: orchestration across many servers with far less boilerplate than the official SDK. Even if the agent is as another commenter fairly pointed out, just a LangChain wrapper, the six-line setup and server manager are a nice DX upgrade.
What’s still missing is structured error semantics. Right now, when a tool explodes the LLM only sees a raw stack trace, so it can’t decide whether to retry or bail. Today, I saw another Show HN post on MCP here: https://news.ycombinator.com/item?id=44778968 which converts exceptions into a small JSON envelope (error, details, isRetryable, etc.) that agents can interpret. Dropping that into mcp-use’s client loop would give you observability + smarter retries for almost free.
I might be missing some important nuances here between client side and server side MCP error handling, which I’ll leave to the authors to discuss. Just thought there might be a good open source collab opportunity here.