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

Do you use MCP-handler for your MCP ?

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

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

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

Today we want to tell you about our cloud product, Manufact, which is to mcp-use as Vercel is to Next.js. Manufact is an MCP vertical cloud designed for dev teams putting MCP Apps and servers in production.You can ship, iterate on, test and monitor your MCPs, and get them ready for the store submissions. All with the best developer and agent experience in mind.

Here is a demo video of the product: https://www.youtube.com/watch?v=R2rbr5OT9LI.

We have been working on MCP since April 2025. Our first focus was making it easy to build agents that could use any MCP server, and a lot of people started using our SDKs. Then the harness revolution kicked off: Claude Code, Claude Cowork, ChatGPT, Codex, OpenCode started shipping agent harnesses that made most standalone agent frameworks redundant. That pushed us to the other side of the connection, the servers. If agents were going to consolidate into a few harnesses, then first-class integration with the rest of a company's systems (i.e. MCP) would become the thing that mattered, so we started building up our server SDKs.

Then in succession:

1. Oct 2025. ChatGPT Apps SDK. OpenAI brings app UIs to ChatGPT, built on top of MCP and the work of mcp-ui. 2. Late 2025. The stores open. ChatGPT starts accepting app submissions, Claude grows its connector directory with selected partners. 3. Jan 2026. MCP Apps becomes official. SEP-1865 merges as the first MCP extension (io.modelcontextprotocol/ui): one UI standard any host can render.

Today, all the major clients fully support MCP and are opening marketplaces of reviewed MCPs that can be one click installed. All major tech companies have an MCP server, and many of those are reporting that already 15+% of their usage comes from their MCP, and we start to have a good way to distribute them just now.

MCP can return fully interactive UIs. So companies can (1) display data in more meaningful ways to their users (e.g. analytics, ecommerce) and (2) display their branding in some of the most used products on the planet (ChatGPT, Claude etc). Numbers: an engineer at Amplitude reported that their MCP saw a 2x increase in retention after adding UI to their MCP.

Clients (Claude, ChatGPT, Cursor) are starting to dynamically present MCP servers/apps to users, based on their intent. Products will be organically discovered on the chats!

We feel that MCP is reaching its maturity moment. Now that MCPs are starting to be easy to install and discover, there is going to be a huge incentive for users to use them and for companies to create them:

1 - Most work is already done from AI chats, this is not going to stop, MCP gives you a way to interact with products without manually using their dashboards.

2 - MCP allows you to bring the context together in one place: you can read an email, create a ticket while plugged into the source code of your product, or your knowledge base. Aggregation of products that was not possible before, will happen in the chat, orchestrated by increasingly intelligent models.

If AI apps (Codex, Claude Desktop) are the new browsers, as PG said in a recent tweet https://x.com/paulg/status/2069080429236191504, then MCPs are the new websites.

But there is a catch:

- Submission process on the stores is still quite tricky, manual and takes up valuable time. - Hardly anybody knows how to design a good MCP: most of them are 1:1 proxies of the API and are abandoned, since being one shotted a few months ago. - The MCP Spec advances quickly and it is not easy to keep track of the changes, and what they mean for your server. - Auth is still a mystery for most teams (API key in the URL ???). - Most companies are not even aware that MCPs can return interactive UIs. - Clients still have to consolidate behavior, some do dynamic tool discovery, some don't, some persist authentication properly some don't.

We built Manufact and mcp-use to solve these problems. Our SDKs help them build good MCPs, our inspector helps them test locally, and our cloud helps them ship/publish and monitor them in production.

To deploy on Manufact you just need to connect a Github app, pick the repo, we'll detect the framework you are working with and get you a live MCP url as soon as possible.

In our platform, that live URL will be used to give you a chat where you can try/debug your MCP immediately and share it with your team. If you push an update on a new experimental branch, you'll be able to test that as well thanks to preview deployments.

Once your server is ready to go live, we help you make sure that it does not break. You can configure automated tests that will take your MCP server, install it in ChatGPT and Claude and test it. We do not test the model, we test the client (model + harness). This way you reliably know if your server breaks where people use it.

Since publishing on the store is a major distribution unlock for companies (your MCP can be dynamically discovered and one click installed across Claude products, and ChatGPT), we collected a set of requirements that will keep your submission from being rejected. You check this locally before going through the actual review process.

Once your server is live, you'll want to understand how it is used. Our analytics are designed for MCP, so you'll know how many users are hitting your MCP, how many tool calls you receive, from which client.

You can try out https://manufact.com for free today. We have usage-based pricing and on our free account we give free credits for you to try it out. If you have an MCP already, just connect your Github repo and deploy, if not you can build one using our skill and SDKs pretty simply (we will guide you in the onboarding).

We would love to hear feedback about the product in the comments, and hear thoughts from everyone about MCP. Thanks! :)

Comments URL: https://news.ycombinator.com/item?id=48762862

Points: 108

# Comments: 68

You might know us for mcp-use (https://github.com/mcp-use/mcp-use) our open source full stack SDK to build MCP servers and clients.

At Manufact we gave ourselves the mission, and delight, to write as many MCP servers as we could, through this journey we could hone our SDK to offer the best possible developer/agent experience.

Testing/developing MCP servers is a pain because:

- Configuring MCPs in normal clients is not an easy feat. People complain that installing them is not easy, imagine having to refresh them every time you make a change - Testing does not only mean testing tools work one at a time, but making sure agents understand them and can call the tool in the right way/order - If installing an MCP locally is a challenge, it is even more on remote clients where people are going to actually use your products (claude.ai, chatgpt.com) - Model capabilities + system prompt (agent) that will end up using your server vary greatly. Some people might be using Opus 4.7 from Claude Code, some might use Instant on chatgpt.com, the model's ability to call your tool varies a lot. Testing on GPT5.5 locally and testing on ChatGPT with the same model yield very different experiences.

First: local development loop

Two things made web development frameworks like Next and Vite (etc.) better than anything else, HMR and preview on localhost.

What is the preview of an MCP ? In our opinion a chat, every time you npm run dev an mcp-use server we serve an inspector on localhost, automatically connected to your MCP server, it has a BYOK chat, a way to test tools one by one, and super detailed metadata about your MCP server to make sure it is compliant

Interesting technical challenge here was to make an MCP client that runs completely (or almost) in the browser.

About HMR: this was not super easy, there are a few ways to do this, we chose the hard but proper way. We implemented HMR using the protocol primitives, if you change a tool we do not hard refresh the server and cancel the previous MCP session, we send a notifications/tools/list_changed notification (in spec) to the client which knows it should reload the tools. As far as UI elements we use Vite HMR and we forward the UI changes across all elements of the inspector so for instance you can change the UI element your MCP returns and see the change live in the embedded chat. (This is pretty marvellous to look at)

This sped up the development of MCPs by a lot.

You can try it out our inspector by running npx @mcp-use/inspector or just by using our sdk.

Bonus: one thing I do often is launch Claude Code with --chrome enabled and tell it to go to the inspector URL to test the server, this creates a closed loop for the agents that make development of MCP with them much much more predictable

Second: testing on other clients (Disclaimer : this is a cloud feature)

Testing on actual client is possibly more painful. We created an automated testing feature, you define the test cases associated with an MCP server in the regular agent testing shape (user message, expected tool calls, rubrics). Since "Testing on GPT5.5 locally and testing on ChatGPT with the same model yield very different experiences." we need to test on the actual client so we use browser agents to install the app and start the tests directly on the clients themselves.

Once the session is over, you get the results and both screenshots and screen recordings of the conversations. These turned out to be super useful to share new versions of MCP apps between teams as well.

I'd love to hear thoughts and feedback and specifically know how (if) people are testing their MCP servers both in production and locally.

(I started writing MCPs in Feb 25, when no tool was available and hardly any support in clients, I'd love to see how people are doing this today)

Comments URL: https://news.ycombinator.com/item?id=48110929

Points: 6

# Comments: 1

There are three key issues when agents interact with MCP servers traditionally: - Context flooding - All tool definitions are loaded upfront, including ones that might not be necessary for a certain task. - Sequential execution overhead - Some operations require multiple tool calls in a chain. Normally, the agent must execute them sequentially and load intermediate return values into the context, wasting time and tokens (costing both time and money). - Code vs. tool calling - Models are better at writing code than calling tools directly.

To solve these issues, they proposed a new method: instead of letting models perform direct tool calls to the MCP server, the client should allow the model to write code that calls the tools.

This way, the model can write for loops and sequential operations using the tools, allowing for more efficient and faster execution. For example, if you ask an agent to rename all files in a folder to match a certain pattern, the traditional approach would require one tool call per file, wasting time and tokens. With Code Mode, the agent can write a simple for loop that calls the move_file tool from the filesystem MCP server, completing the entire task in one execution instead of dozens of sequential tool calls.

We implemented Code Mode in mcp-use's (repo https://github.com/mcp-use/mcp-use ) MCPClient . All you need to do is define which servers you want your agent to use, enable code mode, and you're done!

The client will expose two tools: - One that allows the agent to progressively discover which servers and tools are available - One that allows the agent to execute code in an environment where the MCP servers are available as Python modules (SDKs)

Is this going against MCP? Not at all. MCP is the enabler of this approach. Code Mode can now be done over the network, with authentication, and with proper SDK documentation, all made possible by Model Context Protocol (MCP)'s standardized protocol.

Hope you like it and have some improvements to propose :)

Comments URL: https://news.ycombinator.com/item?id=45994560

Points: 3

# Comments: 3