Stainless was acquired by Anthropic and is shutting down the product. If you used Stainless to generate MCP servers from your OpenAPI spec, you need a new home for that pipeline. This post walks through one way to handle it, using mcp-use and Manufact Cloud.
What Stainless's MCP feature was doing
Stainless had two MCP-related features that customers depended on.
The first was OpenAPI to MCP generation. You pointed Stainless at your OpenAPI spec and got back a working MCP server, generated as a subpackage of your TypeScript SDK. Every endpoint became a tool. Auth, types, and error handling came from the same generator that produced your SDK.
The second was Code Mode and remote hosting. Code Mode collapsed all your endpoints into two tools, execute and search_docs, so coding agents could write code against your SDK instead of guessing between dozens of tool schemas. Stainless also hosted the remote MCP server for you at your-project.stlmcp.com.
Both are going away. That leaves a gap, because MCP went from experimental to load-bearing fast. The ChatGPT Apps Store, Claude Connectors, Cursor, and Codex all consume MCP servers as a first-class surface.
A moment to think about what you actually want
Before copying Stainless's setup to a new tool one-for-one, the migration is a good moment to ask the bigger question: do you want a 1:1 endpoint-per-tool MCP server, or do you want an MCP App?
A 1:1 MCP server exposes your API to agents that already know what they want to do. Good for power users, coding agents, internal tools. It is what Stainless generated by default.
An MCP App is a curated experience that lives inside ChatGPT and Claude. It has its own widgets, its own flows, and a small set of high-intent tools that map to the things real users want to accomplish. It is what you submit to the ChatGPT Apps Store. It is what gets you in front of end users instead of just developers who already use your API.
Most teams we talk to end up doing both. The 1:1 server for developers and agents. The MCP App for end users. Worth thinking about which one matters more for you before you start.
Why we built the openapi-to-mcp skill
When we started talking to teams about this, the same friction kept showing up. They had an OpenAPI spec. They wanted an MCP server. The options were a black-box generator or starting from scratch.
A generator is fast but you do not control the surface. The names, the groupings, the descriptions, the exclusions all come from the generator's defaults. If you want to merge five CRUD endpoints into one higher-level tool, you cannot. If your spec has internal endpoints that should not be exposed to agents, you have to post-process.
Starting from scratch is the opposite trade-off. Full control, but it takes a week to build out auth, error mapping, schema generation, and the small things that make an MCP server actually pleasant to use.
We wanted a middle path. Fast like a generator. Flexible like writing it yourself. So we shipped it as a skill for Claude Code and Cursor instead of as a CLI tool.
Point your coding agent at your OpenAPI spec and ask it to build an MCP server. The skill knows mcp-use's primitives, our auth patterns, widget conventions, and the common mistakes to avoid. It scaffolds a typed mcp-use server, picks reasonable defaults for tool naming and descriptions, and gives you a working repo in a few minutes.
The reason a skill works better than a generator here: a coding agent does the work, you read the diff before merging, and you keep control over the shape of the surface. If you want to merge endpoints, you ask. If you want to exclude internal routes, you ask. If you want widgets on top, you ask. The skill is a starting point that knows the conventions, not a finish line.
The repo it produces is yours. Standard mcp-use, standard TypeScript or Python, deployable anywhere. No vendor lock-in.
Skill page: https://www.skills.sh/mcp-use/mcp-use/openapi-to-mcp
Or, describe what you want with Vibe
If you do not have a spec, or you want to rethink the surface from scratch instead of porting, there is Vibe. Our AI MCP app builder. Describe what you want. It scaffolds an MCP app, including widgets if you want them, and connects to Manufact Cloud for hosting in one flow.
Better for greenfield. Most Stainless migrations will start with the skill instead.
Deploying on Manufact Cloud
Once you have an mcp-use server in a repo, deploy is a GitHub connection.
- Go to manufact.com/platform/hosting and connect your GitHub.
- Pick the repo. Manufact detects mcp-use and runs the right build.
- Push to main. You get a production endpoint with managed TLS.
- Push to any branch. You get a preview endpoint per branch.
- Set env vars in the dashboard. Roll back from the deploy history if a release breaks.
Two more things that matter for Stainless migrations specifically.
Remote hosting with auth. Stainless's remote servers supported header-based auth, bearer tokens, and OAuth. We support all three. OAuth flows can be templated for APIs that do not natively support dynamic client registration.
Cloud Inspector. Debug your deployed server from any browser. Fire tool calls, inspect JSON-RPC, swap models. No local setup. Useful when your server is in production and you need to figure out why a specific agent call is failing.
If we can help
If you are working through a Stainless migration and want a second pair of eyes, just reach out. Happy to look at your setup, talk through the architecture choice, or pair on the port. [email protected] or DM on the usual places.
We are also doing free migration work for a few teams who want to write it up as a case study together. If that is interesting, say so when you email.
mcp-use is on GitHub. Docs are at manufact.com/docs.
