pzullo

this is something you would handle at the code level as you build your MCP - or better we do not offer those yet at platform level as it always seems that is something developers would put in the code - which shape would you imagine ?

on claude you'll need an enterprise and team account here is their post about it https://claude.com/blog/observability-for-developers-buildin... on chat you can find it in the openai platform https://platform.openai.com/apps-manage - need a paid account too

Thanks for asking we have several! here is our own, it is both on the ChatGPT https://chatgpt.com/apps/manufact/asdk_app_69cbfd610c3881919... and Claude Connector store https://claude.ai/directory/connectors/manufact

Thanks for the comment I wrote this piece that goes a bit into this https://manufact.com/blog/what-is-an-mcp-app

TLDR Claude does it today, Chat will probably start soon.

happy to onboard you personally! We did a stainless migration two days ago :)

Thanks for the comment! Vercel is a generic cloud provider, so you won’t get any of the MCP specific features (listed in the post) and development experience - monetization is still not regulated by the protocol, so people would pay for your product before using your MCP, then you can charge based on subscription or usage as usual!

Do you use MCP-handler for your MCP ?

noted! thanks for the feedback, will be gone soon edit: gone

thanks!

thanks!

hey thanks for the feedback, we do not really offer a "set" of pre made MCPs that we could show pre signup, unfortunately our platform requires you to deploy something to use it - we try to give an overview of all the features in our "Platform" section in the navbar on top

a few thoughts for MCP: - typescript "runs" in the browser, which is very handy to develop browser side MCP Clients - for similar reasons it is the only real option to develop UIs for MCP Apps for instance

not particularly related to MCP: as most products rely on external APIs provided by the labs (ChatGPT wrapper as we used to call them) frontend languages become more important

with our SDK we provide many adapters to popular authentication providers which basically provision oauth on your server in one line of code, here the docs https://docs.mcp-use.com/typescript/server/authentication/in...

also we ship templates for you to get started https://manufact.com/templates

thank you so much we have put a lot of love into our product!

pricing: we offer several credit based products that have different cost - requests, build minutes, eval runs, checklist all have different unit cost the breakdown is here https://docs.manufact.com/dashboard/billing thanks for pointing out that it should be more transparent!

auth: we published a few blogs https://manufact.com/blog/oauth-mcp https://manufact.com/blog/authentication

+ lots of auth templates you can start from https://manufact.com/templates

+1 !! Thanks for putting it so clearly, also CLIs and REST have their space in some applications, I think MCP is a way to organize them and distribute them better

This is an interesting approach and I just saw your post on reddit too, good stuff!

Why did you use convex as backend?

We have it ! https://github.com/mcp-use/mcp-use-ts

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

I'd love to hear what you do not like about their client. What issues does it have ?

Nice! shoot us a message on Linkedin :)

Thanks :)

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.

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.

No

What other clients are you referring to ?

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 ?

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.

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.

That is nice, is this like a local E2B ?