# Build ON The Cloud



> Build an app or widget inside The Cloud — described or coded, hosted by us, sandboxed by default, scoped by manifest, listed through the share gate. Idea to installable in under 10 minutes.



## Build ON The Cloud

You want an app or widget living inside The Cloud. A Studio app is a real multi-file app — you describe it or code it, **The Cloud hosts it**, it runs sandboxed by default, it is scoped by a manifest, and it lists through the share gate. You never own a server.

> **What you need** — An AI client connected to The Cloud over MCP (Claude Code, Claude Desktop, Cursor, or any MCP client) and one idea. That is the whole toolchain — the build tools live on the MCP endpoint, so your AI drives them for you.

## Quickstart

1. **Connect your AI to The Cloud** — One line. The browser opens once to sign in — no secret is copied or stored. Full options on the [Connect INTO The Cloud](/docs/connect-into-the-cloud) page.

```bash
claude mcp add --transport http the-cloud https://mcp.thecloud.so/mcp
```

2. **Ask it to build the app** — Describe what you want. Your AI calls `createStudioApp` to scaffold a real multi-file app in your workspace, then writes the files with `writeStudioAppFile`.

```text
Build me a Studio app: a tip calculator with a clean, calm UI. Keep it single-page.
```

3. **See it running** — The app is already hosted. Your AI calls `renderStudioApp` to headlessly screenshot it and read back any console errors, and `checkStudioApp` for route health — so it can verify the app works before handing you the link. Open that link and it is live.

4. **Iterate — the dev loop** — Ask for a change. Your AI edits files with `editStudioAppFile`, re-renders to verify, and the hosted app updates. Run `lintStudioComposition` to confirm the app keeps its scroll-shell guarantee. This is the whole loop: edit → render → verify.

## Manifest and scopes

A Studio app declares what it may reach in its **manifest**. Your AI edits it with `editStudioAppManifest`. The manifest names a closed set of capability scopes; the tools the app may call are a subset of what those scopes imply, brokered per call through a single choke point.

- **Deny by default. **An app can reach nothing consequential until its manifest requests the scope and you grant it.
- **Destructive tools are held higher. **They require an explicit per-tool grant and pass human review at the share gate — never a blanket scope grant.
- **The broker is the only door. **The app talks to The Cloud through the postMessage broker; it has no ambient network egress (sandboxed with connect-src 'self').

## Hosting

There is nothing to deploy. The Cloud hosts the app the moment it exists, serving it sandboxed from an opaque origin. Framework hosting handles the build. Host-for-you is the headline — you keep writing the app, not the infrastructure.

## List it

Everything you build is Private by default. When you are ready to share, your AI calls `shareStudioApp` or `setStudioAppVisibility` — and because publishing widens exposure, **it only takes effect once you approve it in The Cloud**. Approved apps list in Explore, where others can discover and adopt them.

> **Consent is a floor, not a setting** — An AI can request a share; it can never self-approve one. The same rule protects every app you build. Read the whole model on the [Safety classes & the consent law](/docs/safety-and-consent) page.

## Where to go next

- [Connect INTO The Cloud](/docs/connect-into-the-cloud) — the other golden path: make your own service a tool here.
- [Tool reference](/docs/tool-reference) — every Studio tool, generated from the live registry.
- [Safety classes & the consent law](/docs/safety-and-consent) — the governance that makes the platform trustworthy.