Most agent tools stop at retrieval. They fetch a document, query an API, look something up — and then hand the results back for a human to act on. That is useful, but it is not building. The moment you want an agent to actually ship software, it needs somewhere to do the work: a place to write files, install dependencies, run a process, and expose the result.
The cleanest way to give it that is a single MCP call that provisions a real server the agent controls. No dashboard, no ticket, no human in the provisioning loop. The agent asks for a server and gets one.
Quick answer
An MCP-compatible assistant can provision its own persistent server by calling a single tool. That server is a sized compute box the agent owns: it can create projects inside it, write and run code, inspect logs, and publish each project to a stable URL. Because the whole surface is exposed over MCP, the agent operates it directly instead of handing a setup checklist back to you.
Key takeaways
- One tool call provisions a persistent server the agent controls end to end.
- A server holds multiple projects; each project is a workspace with its own stable URL.
- Projects are private by default, so nothing is public until you decide it is.
- The same capabilities are available over a plain API key for non-MCP callers.
- Because it is MCP-native, any compatible host can drive it without custom glue.
The model: servers, projects, URLs
Three ideas are worth getting straight before the first call, because they shape everything the agent can do.
A server is a sized compute box — small, medium, or large. It is the environment the agent builds in, with persistent files that survive between tasks. Provisioning one is the single call that starts everything.
A project is a workspace and app that lives inside a server. One server can hold several projects, each with its own files, its own slug, and its own URL. This is how an agent can maintain a dashboard, a webhook tool, and a landing page side by side without them colliding.
A URL is what makes a project real. Every project gets a stable address that survives visibility changes, so the link you review in private is the exact link that goes live. A URL is the artifact that turns generated code into usable software.
What the one call does
The provisioning call — create a server — is deliberately minimal. The agent names a tier and gets back a persistent box it owns. From there the agent has a small, composable set of tools to do the actual work:
| Tool | What the agent does with it |
|---|---|
| Create server | Provisions a persistent, sized compute box |
| Create project | Opens a workspace and app inside a server, private by default |
| Write and run | Adds files, installs dependencies, and runs commands |
| Inspect | Reads logs and output to check its own work |
| Deploy | Publishes a project so its stable URL serves traffic |
The design goal is that an agent can go from "I need to build a tool" to "here is the URL" without any step where a human copies something into another system. That end-to-end loop is what separates MCP tools that ship software from tools that only fetch data.
Private by default is the safety net
Autonomy without a checkpoint is how a half-finished app ends up public. So every project starts private. The URL exists and is stable, but it serves no public traffic until the agent — or you — sets it to public.
That means you can let the agent build freely, review the running result, ask for changes, and only then publish. The slug never changes when you flip visibility, so there is no re-deploy step where something could quietly differ from what you approved. The full reasoning is in private by default: reviewing agent-built software before you ship it.
Not using MCP? Use the key
MCP is the cleanest path, but it is not the only one. Every capability the agent gets over MCP is also available over a plain HTTP API authenticated by an API key. If your agent framework does not speak MCP, or you are wiring this into an existing backend, you provision a server with an authenticated request and drive it the same way.
This matters for teams validating a build: you are not locked into one host or one protocol. The server, the projects, and the URLs are the same underneath.
Connecting your host
Because the surface is MCP-native, any MCP-compatible host can drive it without custom integration code. You point your assistant at the MCP endpoint, and the provisioning and build tools appear as callable tools. The integrations page lists the hosts you can connect today, and there is a raw connection option for anything MCP-compatible that is not on the list.
The practical upshot for a developer: you do not write a provisioning adapter. You connect a host, and your agent can create a server on its next turn.
A realistic first loop
Put together, a first session looks like this:
- Connect your MCP-compatible host to the endpoint.
- The agent calls create-server and gets a persistent box.
- It creates a private project and writes a small app into it.
- It runs the app, reads the logs, and fixes what is broken.
- It hands you a private URL to review.
- You approve, and the same URL goes public.
Nothing in that loop required you to leave the conversation or provision anything by hand. That is the whole idea: the agent does not describe the infrastructure it needs — it asks for it and uses it.
FAQ
What does the single provisioning call actually create?
A persistent, sized server the agent controls. It has durable files, can run processes, and can host multiple projects, each with its own stable URL.
Do I have to approve the server before the agent gets it?
No. The agent provisions its own server without a human in the loop. Your controls are the plan limits and budget caps, which bound what it can create and spend.
Can one server run more than one app?
Yes. A server holds multiple projects up to its tier's cap, and each project is an independent workspace with its own URL.
What if my agent framework does not support MCP?
Every capability is also exposed over an HTTP API authenticated by an API key, so a non-MCP agent can provision and drive servers the same way.
Is anything public by default?
No. Projects are private by default and only serve public traffic once visibility is set to public. The URL stays the same across that change.
Related reading
- MCP tools should do more than fetch data. They should ship software.
- Why AI agents need persistent workspaces
- Private by default: reviewing agent-built software before you ship it
- Connect an MCP-compatible host