QUIC for the kernel (lwn.net)

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 (15)

cap_andrea · 1h ago

Love this! Finally someone breaking open the MCP ecosystem for real dev use. mcp-use looks like the right balance between power and simplicity. The agent abstraction + tool discovery is super smart.

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?

pzullo · 1h ago

Thanks so much! The ikea was such a cool thing do to, here is the video btw https://www.reddit.com/r/mcp/comments/1jxdi4g/i_wrote_an_mcp...

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.

0xDA7A · 1h ago

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

pzullo · 11m ago

We did! Basically we have a meta layer between the Agent and the MCP servers you give to the clients.

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.

jellothere · 2h ago

Really great work! We’ve been integrating LLMs into production chat-based workflows for a while, and mcp-use has given us the biggest DX boost we’ve seen all year. It strips away the boilerplate of the official SDK, so spinning up a new MCP backend becomes almost a copy‑paste job.

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.

pzullo · 1h ago

That is awesome to hear, that is exactly what we had in mind when writing the library, any feedback or improvements that could reduce the work from hours to minutes now ?

zwaps · 17m ago

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.

pzullo · 8m ago

Valid feedback, we did not put as much work on the agent as we did for the client and MCP side yet, but we plan to write a cleaner more composable MCPAgent as well. Actually I would be super happy to hear what you consider a standard here, something like https://openai.github.io/openai-agents-python/ ?

kenlo · 2h ago

Thank you for sharing this! At Product Weaver we love how mcp-use makes our life easier when accessing MCP servers like Jira, Linear, Notion and many others. We like the clean code we can write, as it's vital for maintaining it. Ad maiora!

pzullo · 2h ago

!!! Thank you so much, love to hear that !!!

alessiapacca · 2h ago

Hey, this is really cool. But why should I use this and not the official SDK?

pzullo · 2h ago

I think the original SDK is quite low level, not assembly low level, but if you want to get started and expose a tool to an LLM you would have to write something in the neighborhood of ~200 lines of code, and they would have to be wrapped in a double nested async loop. If you want to develop authorization with Dynamic Client Registration, it going to be another ~1000 lines. I think many developers will want to avoid that. Plus, if the spec changes, and it does very often, you would have to keep track of it, we take care of that for you.

hubraumhugo · 24m ago

Since you're in the current YC batch, why is this a Show HN instead of a Launch HN?

zechengz · 35m ago

Love this! This is super helpful!

pzullo · 7m ago

Thanks!!