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.
Thanks for the mention! I'm the author of Mcp-error-formatter, which was mentioned above. Exactly right about the client/server complexity. I've been working on this exact problem. Client-side heuristics can catch timeouts and HTTP codes, but nuanced business logic errors need server cooperation.
The interesting part is dual error representation: devs need full stack traces for debugging, but LLMs need clean structured metadata for retry decisions. Plus you want error telemetry flowing to observability systems.
Question for the mcp-use authors: How do you handle error propagation in multi-server setups? If Server A times out but Server B is healthy, does the agent know which server failed and whether to retry or switch servers? And are you capturing error patterns to identify flaky servers or consistently failing tool calls? The retry orchestration across multiple MCP servers seems like a really interesting problem.
Hey, awesome work with the error formatter, as explained above I think error creation falls more under the server responsibilities if it contains any logic about the error (e.g. is retryable). It would be interesting to hear your opinion on a format for LLM side errors.
Regarding the multi server failure case: (without server manager) today if one of the server dies the agent will keep going, I do not think this is a particularly thought through decision, probably the client should error out, or let the agent know that the server is dead. (with server manager) the agent will try to connect to the dead server, get an error, possibly retry, but if the server keeps being unable to connect to, the agent will eventually bail. Indeed it is an interesting problem. How do you see the responsibility split here ?
Regarding the flakyness, ultimate dream, but requires some more work, I think that monitoring this is something that the client has a privileged position of doing, we will do it for sure. I think this is going to be great feedback for companies building servers. Happy to coordinate on ideas on how to do this best.
Hey thanks for the comment, the work from https://github.com/bjoaquinc/mcp-error-formatter is great. I will definitely put some version of this into one of the next releases. Just opened an issue mentioning this thread.
The problem with the package above is that it is server side, and I think it should be. Server is the one that knows (has responsibility to know) if a tool is retryable and has informations about the error, and fairly so.
I see though how some sort of improved error formatting could be introduced in the client as well, but it shouldn't contain any logic about the error, rather format the error in the best way possible (in the direction in which it is best understandable by LLMs).
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
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.
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 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.
We designed this slightly differently where one can use the client directly an not only in our agent, the structure is more focused around the MCP functionality.
I'm confused -- I didn't see a single example in you readme or docs that uses the client WITHOUT your agent. Trying to understand if this is an alternative to FastMCP. I don't want your agent.
Hey, we have an example in our readme and docs about how to build your custom agent. but you are right, we should probably fill the client section of the documentations with examples on how to use the client API in more details. Will be done!
The extent to which this is an alternative to FastMCP depends a bit on your use case. As long as you are not interested at all in any agent, they are alternative, but if you want to create an agent we will be closer to what you need. We designed our client with the creation of an agent in mind, and will continue to do so, the design is geared towards this and we have examples of how to use this in our agent.
FastMCP client is very similar today. I see the influence of our design in their implementation. We spoke to the authors a month back and the position was that they wanted something they could use to test their own servers, so the ultimate intention was different. Not sure where it is going to go.
In my case I'm creating the agent in a custom way (using the BAML framework), so I don't need the agent part of your solution. FastMCP works ok but has some issues, so if you have a better client than can be used as a replacement, I would potentially be interested.
> 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.
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?
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/ ?
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
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.
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.
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.
Hey jijji, fair point, I assumed that the hn audience and/or the people interacting with the website would already know about MCP.
If you're not familiar, MCP is an open-source protocol created by Anthropic and later adopted by all major model providers. It defines how LLMs communicate with external applications and services.
More specifically, MCP standardizes the interaction between an MCP server, where the business logic resides, and a client, loosely speaking an LLM that consumes it. The MCP server exposes primitives like tools, resources, and prompts, which the client can use to perform various operations. The communication protocol used is JSON-RPC 2.0, and interaction between the client and server occurs either locally through stdio streams or remotely over streamable HTTP.
Here are some of the good things about it:
Easier integration into agents:
From an agent development perspective, MCP simplifies integrating external capabilities. Previously, you'd have to write custom integrations, which is sometimes difficult or limited by the availability of public APIs. Now, you can directly plug in an MCP server, if provided. if you had to write a custom integration, using MCP is beneficial as well, as it separates integration logic from agent logic, making it easy to hot swap any of the two.
Standardized interface and incentives for companies:
Because MCP standardizes communication, developers can create MCP servers independently from the specific LLM or agent consuming them. This compatibility with clients like ChatGPT, Claude Desktop, and mcp-use provides a strong incentive for companies to develop MCP servers for their own applications. This is great because they are the ones that know best how to do this (and can).
Widespread Adoption:
A protocol's value heavily depends on its adoption, and MCP is sticking real well. Companies, developers, and major model providers are mostly on board with MCP.
I'd love to know if somebody has other positive points or negative points about mcp and can share it here. Some are across the thread already.
(tomhow and I were both replying at the same time)
I see what you mean and yeah it often happens that friends or users of a project try to "help out" in this way. It's fine on many other platforms, so it's more of a misunderstanding than anything. People don't realize that it runs against HN's culture.
Yeah I don't even see the point of this. There's enough MCP clients now and the whole point of MCP is to make tools available to any LLM that can use tools.
Related, in the sense that it is also a way to connect any LLM to any MCP. Not sure what you meant, I.e when there’s a discussion of a feature I think it’s normal to mention other systems with similar features?
I answered this question in a similar case a few months ago: https://news.ycombinator.com/item?id=43111524. If you read that and still have a question that isn't answered there, let me know!
Super cool project — love the direction you're taking with simplifying MCP integration and tooling! The search layer between agent and servers is a clever abstraction to reduce cognitive + compute load. Also appreciate the IKEA curtain flex
Would love to see how this evolves toward more dynamic infra setups. Keep it up!
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?
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.
nice. i feel interaction with mcps now is sort of broken, and building on top of the sdk is a pain. being compliant with the specification is a way better take.
i'm curious to see how this scales. and it's a good starting point on reshaping our interaction with basically every single application.
Hey thanks for the comment (xmcp in the house)! I can certainly agree with the sdk being a pain, why do you feel that the interaction is broken ? in which way ?
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.
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 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!
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.
As somebody who has done both- mcp-use makes it very very simple.
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
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.
Thanks for the mention! I'm the author of Mcp-error-formatter, which was mentioned above. Exactly right about the client/server complexity. I've been working on this exact problem. Client-side heuristics can catch timeouts and HTTP codes, but nuanced business logic errors need server cooperation.
The interesting part is dual error representation: devs need full stack traces for debugging, but LLMs need clean structured metadata for retry decisions. Plus you want error telemetry flowing to observability systems.
Question for the mcp-use authors: How do you handle error propagation in multi-server setups? If Server A times out but Server B is healthy, does the agent know which server failed and whether to retry or switch servers? And are you capturing error patterns to identify flaky servers or consistently failing tool calls? The retry orchestration across multiple MCP servers seems like a really interesting problem.
Hey, awesome work with the error formatter, as explained above I think error creation falls more under the server responsibilities if it contains any logic about the error (e.g. is retryable). It would be interesting to hear your opinion on a format for LLM side errors.
Regarding the multi server failure case: (without server manager) today if one of the server dies the agent will keep going, I do not think this is a particularly thought through decision, probably the client should error out, or let the agent know that the server is dead. (with server manager) the agent will try to connect to the dead server, get an error, possibly retry, but if the server keeps being unable to connect to, the agent will eventually bail. Indeed it is an interesting problem. How do you see the responsibility split here ?
Regarding the flakyness, ultimate dream, but requires some more work, I think that monitoring this is something that the client has a privileged position of doing, we will do it for sure. I think this is going to be great feedback for companies building servers. Happy to coordinate on ideas on how to do this best.
Hey thanks for the comment, the work from https://github.com/bjoaquinc/mcp-error-formatter is great. I will definitely put some version of this into one of the next releases. Just opened an issue mentioning this thread.
The problem with the package above is that it is server side, and I think it should be. Server is the one that knows (has responsibility to know) if a tool is retryable and has informations about the error, and fairly so.
I see though how some sort of improved error formatting could be introduced in the client as well, but it shouldn't contain any logic about the error, rather format the error in the best way possible (in the direction in which it is best understandable by LLMs).
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.
Great idea! Definitely going to use it. What are some good reasons to prefer this over fastmcp clients? https://gofastmcp.com/clients/client
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 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:
https://langroid.github.io/langroid/notes/mcp-tools/
We designed this slightly differently where one can use the client directly an not only in our agent, the structure is more focused around the MCP functionality.
I'm confused -- I didn't see a single example in you readme or docs that uses the client WITHOUT your agent. Trying to understand if this is an alternative to FastMCP. I don't want your agent.
Hey, we have an example in our readme and docs about how to build your custom agent. but you are right, we should probably fill the client section of the documentations with examples on how to use the client API in more details. Will be done!
The extent to which this is an alternative to FastMCP depends a bit on your use case. As long as you are not interested at all in any agent, they are alternative, but if you want to create an agent we will be closer to what you need. We designed our client with the creation of an agent in mind, and will continue to do so, the design is geared towards this and we have examples of how to use this in our agent.
FastMCP client is very similar today. I see the influence of our design in their implementation. We spoke to the authors a month back and the position was that they wanted something they could use to test their own servers, so the ultimate intention was different. Not sure where it is going to go.
In my case I'm creating the agent in a custom way (using the BAML framework), so I don't need the agent part of your solution. FastMCP works ok but has some issues, so if you have a better client than can be used as a replacement, I would potentially be interested.
I'd love to hear what you do not like about their client. What issues does it have ?
I have used mcp-use to write some demo functionality and it is very easy to use and works great!
Thanks, I appreciate that!
> 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.
That is nice, is this like a local E2B ?
Thank you. Yes, it is. Let me know if I can help integrating it or I can send a PR.
How does the sandboxing work? Is it cross platform? Options for filesystem/netork?
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?
Introduced the tool at Porsche last week. Looks like there might be a big corporate partnership coming up
Nice! shoot us a message on Linkedin :)
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.
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/ ?
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
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.
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.
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.
Hey jijji, fair point, I assumed that the hn audience and/or the people interacting with the website would already know about MCP.
If you're not familiar, MCP is an open-source protocol created by Anthropic and later adopted by all major model providers. It defines how LLMs communicate with external applications and services.
More specifically, MCP standardizes the interaction between an MCP server, where the business logic resides, and a client, loosely speaking an LLM that consumes it. The MCP server exposes primitives like tools, resources, and prompts, which the client can use to perform various operations. The communication protocol used is JSON-RPC 2.0, and interaction between the client and server occurs either locally through stdio streams or remotely over streamable HTTP.
Here are some of the good things about it:
Easier integration into agents: From an agent development perspective, MCP simplifies integrating external capabilities. Previously, you'd have to write custom integrations, which is sometimes difficult or limited by the availability of public APIs. Now, you can directly plug in an MCP server, if provided. if you had to write a custom integration, using MCP is beneficial as well, as it separates integration logic from agent logic, making it easy to hot swap any of the two.
Standardized interface and incentives for companies: Because MCP standardizes communication, developers can create MCP servers independently from the specific LLM or agent consuming them. This compatibility with clients like ChatGPT, Claude Desktop, and mcp-use provides a strong incentive for companies to develop MCP servers for their own applications. This is great because they are the ones that know best how to do this (and can).
Widespread Adoption: A protocol's value heavily depends on its adoption, and MCP is sticking real well. Companies, developers, and major model providers are mostly on board with MCP.
I'd love to know if somebody has other positive points or negative points about mcp and can share it here. Some are across the thread already.
Need a typescript alternative
We have it ! https://github.com/mcp-use/mcp-use-ts
it can be used via claude code on ubuntu too
what are you referring to ?
Not sure what is going on, but I see a lot of 1-karma-point HN users hyping this.
It's most likely just over-exuberance from people who know the founders or use/love the project and want to support it. It doesn't look orchestrated.
(tomhow and I were both replying at the same time)
I see what you mean and yeah it often happens that friends or users of a project try to "help out" in this way. It's fine on many other platforms, so it's more of a misunderstanding than anything. People don't realize that it runs against HN's culture.
I've moved those comments to a stub post now (https://news.ycombinator.com/item?id=44752791).
Yeah I don't even see the point of this. There's enough MCP clients now and the whole point of MCP is to make tools available to any LLM that can use tools.
What other clients are you referring to ?
I'm not sure how this relates to the comment you replied to?
We detached this subthread from https://news.ycombinator.com/item?id=44751518 and marked it off topic.
We also detached https://news.ycombinator.com/item?id=44751518 from https://news.ycombinator.com/item?id=44751285 to make it a root comment, given that the author agreed it didn't make sense to be a reply (https://news.ycombinator.com/item?id=44751620).
Appreciate your work, Tom!
Very kind :)
I see the confusion :) I meant my comment not as an actual reply to my own comment but more as an afterthought.
OK, we detached that comment to make it a root comment. Explained in detail here: https://news.ycombinator.com/item?id=44752785.
Related, in the sense that it is also a way to connect any LLM to any MCP. Not sure what you meant, I.e when there’s a discussion of a feature I think it’s normal to mention other systems with similar features?
Since you're in the current YC batch, why is this a Show HN instead of a Launch HN?
I answered this question in a similar case a few months ago: https://news.ycombinator.com/item?id=43111524. If you read that and still have a question that isn't answered there, let me know!
[stub]
[explained at https://news.ycombinator.com/item?id=44752814]
Good, I have not dig into the code, just one question: how to deal with other stuff supplied by MCP server, I mean besides tools, server also supplied "resources", "prompt" and other functionality, I saw some struggle here(https://github.com/vincent-pli/mcp-cli-host/blob/main/docs/r...) and here(https://github.com/vincent-pli/mcp-cli-host/blob/main/docs/p...),
Super cool project — love the direction you're taking with simplifying MCP integration and tooling! The search layer between agent and servers is a clever abstraction to reduce cognitive + compute load. Also appreciate the IKEA curtain flex
Would love to see how this evolves toward more dynamic infra setups. Keep it up!
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?
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.
nice. i feel interaction with mcps now is sort of broken, and building on top of the sdk is a pain. being compliant with the specification is a way better take.
i'm curious to see how this scales. and it's a good starting point on reshaping our interaction with basically every single application.
Hey thanks for the comment (xmcp in the house)! I can certainly agree with the sdk being a pain, why do you feel that the interaction is broken ? in which way ?
Interesting project! Today, AI projects move progress forward. Good luck to you!
Thanks :)
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.
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 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!
!!! Thank you so much, love to hear that !!!
Love this! This is super helpful!
Thanks!!
This is super cool! Building with MCP is such a hassle right now, this is a game changer.
thankss! I appreciate you
belli e bravi
grazie mille!
[flagged]
No
Hey, this is really cool. But why should I use this and not the official SDK?
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.
As somebody who has done both- mcp-use makes it very very simple.
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