What just happened with MCP?
MCP (Model Context Protocol) is an open standard that lets AI agents connect to a company's tools, data, and systems through a common interface. In early 2026 it crossed a threshold: agent "harnesses" like Claude Code, Codex, and ChatGPT consolidated, app stores opened, and SEP-1865 merged as the first official MCP UI extension. The stack is standardizing fast. The rules for what those connections may do are not.
Two things are now true at once. First, the plumbing is settled enough to build on. Manufact — the YC S25 company formerly known as mcp-use — launched an "MCP vertical cloud" to ship, test, and monitor MCP servers, positioning itself as "Vercel for MCP." That's a reasonable read of where value is moving.
Second, and less discussed: an MCP server is a set of tools, and tools take actions. The interesting question for any operating company isn't whether it can expose its systems over MCP. It's whether it should let an agent write to them at all.
Why do servers matter more than agents now?
Answer capsule: Agent frameworks are consolidating into a few harnesses shipped by OpenAI and Anthropic. When the agent layer commodifies, the differentiator shifts to integration — how well a company's systems connect to those harnesses. That's the server side of MCP, and it's where the durable engineering work now lives.
Manufact's founders describe the shift plainly: the "harness revolution" made standalone agent frameworks largely redundant, so they pivoted from building agents to building server SDKs. If a handful of harnesses win, then first-class integration with the rest of a company's systems becomes the thing that matters.
We agree with the direction. An agent harness — the runtime environment (Claude Code, Codex, ChatGPT) that hosts a model and lets it call tools — is becoming infrastructure you rent, not build. What you own is the connection to your data and workflows. That connection is an MCP server.
What's the risk nobody's pricing in?
Answer capsule: MCP tools can read and write. Most production discussion focuses on shipping and monitoring servers, not on constraining their write actions. An agent with a poorly scoped MCP server can mutate records, trigger workflows, or move money — with no human in the loop and thin audit trails. That's the gap.
Deploying an MCP server is a deployment problem. Governing one is a control problem, and they are not the same.
Consider what "put your MCPs in production" actually means for an operating company:
- Write access. A tool named
update_leaseorapprove_invoicedoes exactly what it says when the model calls it. - Ambient authority. The agent runs with whatever credentials the server holds, often broadly scoped for convenience.
- Weak provenance. When an action lands in your system, can you reconstruct which prompt, which model, and which reasoning produced it?
Anthropic's own MCP documentation flags tool permissioning and human confirmation as core safety considerations — the standard assumes hosts will add controls, not that servers are safe by default.
How should operating companies deploy MCP servers?
Answer capsule: Treat every write tool as a proposal, not a command. The safest MCP architecture lets an agent draft an action, stages it for review, and requires an accountable human or policy check before anything commits. This preserves the speed of agents while keeping mutations governed and auditable.
This is Vantrow's category thesis, and MCP makes it concrete: propose, never commit. In practice:
- Split read from write. Expose read tools freely. Gate every write tool behind a staging step.
- Stage the action. The agent's output is a proposed change — a diff, a draft, a queued transaction — not an executed one.
- Attach provenance. Record the prompt, model, tool call, and inputs alongside the proposal.
- Require an accountable approval. A human or an explicit policy commits the change. Nothing mutates silently.
This is the difference between governed AI and autonomous agents. Governed systems don't slow teams to a crawl; they move the risky moment — the commit — to a place where it can be reviewed.
Is "Vercel for MCP" the right model?
Answer capsule: It's a good deployment model and probably the right layer for the developer experience of shipping and monitoring servers. But deployment convenience is not governance. An operating company still needs a control layer that decides which tool calls become real actions — and that layer belongs closer to the systems of record than to the deploy pipeline.
Manufact solving ship-test-monitor-submit is genuinely useful; that workflow was painful. The caution is treating a smooth deploy path as sufficient. The question that outlasts any store submission is: when the agent calls the write tool, what checks fire before the record changes?
If the answer is "none, it just executes," the standardization of MCP has made a governance gap easier to reach production.
FAQ
Note on figures: this piece cites qualitative product and standards claims from Manufact's launch post and Anthropic's MCP documentation; it deliberately avoids invented statistics.