Show HN: Play NYT Connections in the Terminal (github.com)
Photographs of Auto Polo (ca. 1912) (publicdomainreview.org)
How much would it cost to make an iPhone in America? (medium.com)
Show HN: Mcp-use – Connect any LLM to any MCP
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.
The client is comparable, but we support multiple connections at once, we handle task management for you (so you do not need to async with in our code), and we have an agent that you can get started with. Also I do not think FastMCP will go into the agent side of things in the Agent - Client - Server spectrum, so if you need support on that side (integrations with other frameworks, providers etc) you'll find it here :)
However, the agent is really just a wrapper of Langchain AgentExecutor. This doesn't seem like something someone would want to put into production.
From a company perspective that’s huge: adding a new chatbot feature that used to take a couple of sprints and a lot of glue code can now be done in hours instead of weeks.
We call this server manager, basically instead of exposing all the tools from all the servers at once to the agent we only expose 4 meta tools: - list servers() - connect to server(server_name) - search_tool(query) - disconnect from server(server_name)
So that the agent can dynamically connect to specific servers without flooding its context with all the tools.
The search tool basically performs semantic search over all the tools from all the servers returning the top N results (tools) and the server they belong to so that the agent can connect to the right server.
A demo of this is here https://www.reddit.com/r/mcp/comments/1k598v9/give_your_agen... where I hid a useful tool in a sea of useless ones (10 useful, 3000 useless) and the agent was able to find and use the right one.
Would love to see how this evolves toward more dynamic infra setups. Keep it up!
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.
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
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.
Also, hacking an IKEA curtain with MCP is an all-time flex.
Curious if you’re planning to build infra on top or keep it strictly dev tools?
Yes we plan to do more infrastructure work for sure, the idea is that larger teams will need a centralized place where they can configure their MCPs, monitor them, and define access control rules, create agents with specific permissions and capabilities. The old infrastructure (in the dev tool sense) does not really lend itself well to this new use cases.
We are building in this direction and we plan to open source this aspect as well, for now we are working closely with few large companies to first understand their pains deeply.
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.
If you are at all familiar w/ python back-end development, it's literally just as easy use this tool to make an API as it is to put your MCP into claude desktop.
MCP SDK is not hard to do per se... but it's more than a 5 minute job