This guide is the the official TypeScript SDK entry from our seven-framework deploy comparison. We shipped the same example on Manufact Cloud: an echo tool and a greet_widget that returns a MCP Apps view. Below is the deploy path we used; the reference server code is in the second half if you want to reproduce the example.
If you want to run the same deploy pipeline on your repo, connect it in the dashboard. Open the dashboard.
Deploy to Manufact
Manufact Cloud builds your repo with Depot, runs it on Fly, and gives you a stable *.run.mcp-use.com URL with a verified MCP endpoint. The whole flow is GitHub → Cloud → working /mcp.
Push the repo to GitHub
Open the new-server flow
Go to manufact.com/cloud/<your-org>/servers/new and pick Deploy from GitHub. If you've never connected GitHub, the dialog walks you through installing the Manufact GitHub App on the org or user that owns the repo.
Pick the repo and branch
Search for mcp-typescript-greet, select it, leave the branch on main. Manufact runs framework detection in the background: for this repo it'll label it mcp-typescript.
Confirm build and start
The preset auto-fills:
- Build command:
npm run build - Start command:
npm start - Port:
3000
No edits needed. The cloud's generated Dockerfile clones the repo, runs npm install, runs the build, and starts the server.
Click Deploy and watch the logs
The first deploy takes 30–90 seconds (Depot builds a fresh image, Fly cold-starts the machine, the cloud probes /mcp for an MCP initialize response). Once you see Server status: running in the build log, the URL is live.
Smoke-test the URL
You should see both tools, with greet_widget._meta.ui.resourceUri pointing at ui://my-server/greet.html.
Example repo: manufacts/mcp-detect-mcp-typescript
Live /mcp: keen-forge-rsxua.run.mcp-use.com/mcp — serverInfo.name is mcp-detect-mcp-typescript (Manufact server status: running).
Auto-deploy on push
Once the server exists, every push to main triggers a new deployment. Add watchPaths: ["src/**"] in the server settings to limit auto-deploys to source changes only.
The steps above are what we used for the live demo. Your repo can use the same GitHub deploy flow. Open the dashboard.
Reference server
Use this section if you are following along with the same example. If you already have an MCP app to deploy, the GitHub steps above are enough.
What we deployed
- A streamable-HTTP MCP server on Express
- An
echotool that returns text - A
greet_widgettool whose_meta.ui.resourceUripoints at atext/html;profile=mcp-appresource the host renders in an iframe
Project setup
tsconfig.json:
The server
src/index.ts:
registerAppTool does two things server.registerTool doesn't: it accepts the _meta.ui.resourceUri shape and also writes the legacy _meta["ui/resourceUri"] key, so older hosts still resolve the view. registerAppResource defaults the MIME type to text/html;profile=mcp-app when you pass RESOURCE_MIME_TYPE.
What the host sees
tools/list returns:
resources/list returns:
The host fetches the resource, sees the MIME profile, renders it in a sandboxed iframe, and lets the inline App instance receive every tools/call result via the bridge.
Run it
Hit it with the standard MCP probe:
You should see both tools and the greet_widget _meta.ui.resourceUri.
When to reach for it
You want maximum protocol fidelity, no framework opinions, and you don't mind writing your widget HTML by hand. For a single tool with a single view, the boilerplate is fine. Beyond that you'll start factoring out helpers: at which point you've built half of mcp-use and might as well use it.
The full comparison across all seven frameworks is in Deploying Seven MCP Frameworks.









