pzullo

thankss! I appreciate you

grazie mille!

what are you referring to ?

Hey, thanks! Please let us know if we can help with anything once you get started. FastMCP is very good at servers, they just recently started to provide a client.

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 :)

For sanboxing we are using E2B, which spins up a sandbox for the server execution, we run the mcp server command inside the sandbox and expose the stdio stream as an sse from the sandbox remote. You could potentially replace the E2B sanbox with any other. Unfortunately, mcp servers that need access to your filesystem cannot be run on a sanbdox, I believe you could do it with the network, what would be the use case?

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

Thanks, I appreciate that!

Thanks!!

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/ ?

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.

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.

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 ?

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

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.

EDIT:

Demo at https://github.com/mcp-use/mcp-use-cli

Cool stuff!