Manufact Raised $6.3M to Be 'Vercel for MCP Servers' — Here's Exactly What a Generic Git-Push PaaS Doesn't Give You

In February 2026, a company called Manufact raised $6.3M to build something that, on paper, already exists a dozen times over: a platform where you push a git repo and get a running HTTPS service. Manufact's pitch is that this particular flavor of "already exists" — deploying a Model Context Protocol server — is different enough to fund a dedicated cloud for. The tagline is blunt about the comparison it's inviting: Manufact is "to mcp-use as Vercel is to Next.js."

That's a specific, falsifiable claim, so here's the concrete answer. Manufact's Hobby tier costs $25/month for 5 projects, 3 seats, and 30 days of analytics retention. A generically-specced git-push PaaS running the identical MCP server — same CPU, same RAM, same always-on uptime — costs about the same, sometimes less. The $25/month isn't buying more compute. It's buying four things a generic platform's dashboard structurally can't show you, because a generic dashboard doesn't parse the JSON-RPC frames flowing over your MCP server's wire: tool-call-level tracing, session replay of tool-call sequences, an eval gate that runs on every deploy, and a checklist that gets you through OpenAI's and Anthropic's app-store submission process without failing review. That's the actual gap, and it's worth being precise about where it starts and where it stops mattering.

What $6.3M Actually Bought: The Product, the Traction, the Price Tag​

Manufact — until its 2025 rebrand, an open-source project called mcp-use — closed a $6.3M seed round on February 12, 2026, led by Peak XV with participation from Y Combinator, Liquid 2 Ventures, Ritual Capital, Pioneer Fund, True Ventures, and a handful of angels including Supabase COO Ant Wilson. Co-founders Pietro Zullo and Luigi Pederzani, who met at a co-working space in Zurich, had already built real traction before taking the round: the mcp-use SDK has crossed 6 million downloads and 10,300+ GitHub stars, and the company claims roughly 20% of the Fortune 500 has experimented with its libraries, with NASA, Nvidia, and SAP named as users.

The product is three layers stacked on top of that open-source core:

• mcp-use SDK (Python + TypeScript) — the open-source library for building MCP servers and connecting agents to them, unchanged in spirit from the original project.
• mcp-use Inspector — a browser-based debugger for testing an MCP server's tool calls before it ships.
• Manufact Cloud — the actual paid product: connect a GitHub repo once, and every push auto-deploys to a running MCP server in under 60 seconds.

Here's the full pricing ladder, because "hosted platform for MCP servers" is meaningless without knowing what it costs:

Every paid tier ships the same core feature set: preview deployments, GitHub-org deployment, "cold-start prevention," and — the part that actually differentiates this from a generic PaaS dashboard — analytics with session replay, JSON-RPC traces, alerts on regressions, an Inspector that debugs against real clients, and evals that run on every deploy. Founder Pietro Zullo's framing of the problem is direct: developers were "spending too much time on plumbing instead of building." The bet is that the plumbing worth removing isn't the deploy step — every PaaS already removed that — it's everything downstream of deploy that's specific to what an MCP server actually is.

Deploying the Same Server on a Generic Git-Push PaaS​

So take that literally and do it. An MCP server running the streamable-http transport is, at the infrastructure layer, an ordinary HTTP service: it listens on a port, exposes a /mcp endpoint, and needs a public HTTPS URL. There is nothing about that description a git-push PaaS doesn't already handle. Push the repo to Render, Railway, Fly.io, or bex, get a domain and a TLS certificate, done — the same "connect your repo, we handle the rest" motion Manufact runs, just without an MCP-specific label on it.

The cost comparison is close enough that it isn't the interesting number. Render's Starter tier runs $7/month and is production-ready (its free tier sleeps after 15 minutes of inactivity, which would silently kill agent connections — worth knowing if you're tempted to skip straight to "free"). Railway keeps the process persistent with no cold starts and native support for the long-lived connections streamable-http sessions actually need. A self-hosted platform running the same container on owned hardware has no per-project fee at all once the box is paid for. None of these land far from Manufact's $25/month Hobby tier for a comparably-specced single service — the delta is single-digit dollars, not an order of magnitude.

What none of them give you, out of the box, is everything downstream of "the process is running":

• Tool-call-level tracing. A generic PaaS's log viewer shows you HTTP requests and stdout. It has no concept of a JSON-RPC tools/call frame, so a malformed tool response or a client that silently retried the same call five times looks identical to normal traffic in the logs — you're grepping raw request bodies to find it.
• Session replay for tool-call sequences. "Session replay" on a generic platform means replaying HTTP requests. For an MCP server, the unit that matters is a sequence of tool calls within one client session — which tool got called, with what arguments, in what order, against a specific negotiated protocol version. That's a different data model, and no generic APM tool ships it because it doesn't know MCP's wire format exists.
• An eval gate on deploy. Manufact runs evals against your MCP server on every push — checking that tool calls return outputs that actually match expected schemas and values, not just that the HTTP server returned 200. A generic PaaS's health check pings a port; it has no way to know your search_orders tool started returning malformed JSON to a specific client library.
• App-store submission readiness. This is the sharpest, most concrete gap, because it isn't Manufact's opinion — it's OpenAI's and Anthropic's actual requirements. Submitting an MCP server as a ChatGPT app requires identity verification, a domain-ownership token served at a specific endpoint as plain text, tool annotations set correctly (readOnlyHint for read-only tools, destructiveHint for anything that writes or deletes, openWorldHint for tools touching external systems), and every test case passing on both ChatGPT web and mobile. None of that is a deploy problem. All of it is a "did you configure your MCP server correctly" problem, and a generic PaaS has no opinion on MCP tool annotations because it has no reason to.

The Real Gap Is Protocol Literacy, Not Compute​

Line those four up and a pattern falls out: every one of them requires the platform to actually parse and understand MCP's JSON-RPC framing, not just proxy bytes to a container. That's the actual moat, and it's worth being honest about how wide it is on each side.

For a hobby project — one MCP server, a handful of tool calls a day, no plans to list it in the ChatGPT app store — none of this matters. Deploy it on the cheapest git-push PaaS available, tail the logs by hand when something breaks, and the $18-243/month gap to Manufact's paid tiers buys you nothing you'll ever use. This is where the generic-PaaS answer is not just adequate but strictly better: you're not paying for tooling you'll never open.

For a team actually submitting to app stores, or running an MCP server with enough tool-call volume that "grep the logs" stops being a debugging strategy, the calculus flips. A failed ChatGPT app review over a missing destructiveHint annotation costs a resubmission cycle measured in days, not dollars — and a tool that silently degrades because a schema mismatch shipped without an eval catching it costs whatever an agent did with the bad output before a human noticed. That's a real, if hard-to-price, cost a generic PaaS's health check genuinely does not catch.

It's also worth naming the one force actively narrowing this gap over time: MCP's own protocol evolution. The July 28, 2026 specification release moved toward a stateless core specifically designed to run on ordinary HTTP infrastructure — the kind of server that no longer needs sticky sessions or a shared session store to scale horizontally. Every point of friction the spec removes from "run this on generic infrastructure" is one less reason a dedicated MCP cloud's compute layer has an edge. That doesn't touch the observability and store-readiness gap at all — those are tooling decisions, not protocol mechanics — but it's the reason the compute half of "why pay a premium to host an MCP server" keeps shrinking even as the tooling half stays real.

What a Cluster-API PaaS's Own MCP Roadmap Should Take From This​

For a platform like bex — git-push deploy already built, an MCP server on the roadmap so an AI agent can call the same deploy/rollback/logs tools a human uses — the honest read of Manufact's launch isn't "someone else already solved MCP hosting." It's a scoped list of what "MCP-aware" actually has to mean before that claim is true, instead of "deploy an MCP server exactly like any other container" with an MCP label pasted on top:

1. Parse JSON-RPC at the log layer, so a tool call is a first-class entity in observability, not a request body a human has to grep.
2. Add an eval-on-deploy gate, even a minimal one — assert a handful of known tool calls return schema-valid output before a deploy is marked healthy, the same way a health check already gates a web service.
3. Ship a store-submission checklist as tooling, not documentation — validate tool annotations and confirm the domain-verification endpoint is actually serving before a team finds out from a rejected review.

None of that requires becoming a single-purpose MCP cloud the way Manufact is. It requires treating "MCP server" as a workload type with its own health signals, the same way a platform already treats a cron job or a background worker differently from a stateless web service — because the underlying traffic has a shape a generic HTTP proxy can't see into. Deploying an MCP server was never the hard part; understanding what's happening inside the calls once it's running is.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, and give an AI agent the same deploy/rollback/logs tools over MCP that a human operator uses today. Star the repo on GitHub or deploy your first app today.