Tool reference

The workspace’s apps, newest first, with their services.

Create an empty app. Free, even with no balance. Add services to it next (add_service), which needs a positive balance.

One app, with its services and status.

Change an app’s name.

Delete an app and all its services and data. This can’t be undone; confirm with the person first.

An app’s services and whether each is ready.

Plug a service into an app: "compute" runs code (one per app), "database" is SQL (SQLite), "storage" holds files, "email" sends email, "sandbox" enables sandboxes (one per app). Waits until it is ready.

Remove a service from an app. A database or bucket is deleted with all its data. This can’t be undone; confirm with the person first.

An app’s own domains (custom ones and its platform address), each with its status (pending, active, failed), what it means in plain words, and any DNS records still to add. Pending ones are checked again first.

Give an app a custom domain the person owns, like shop.example.com. It’s pending until the domain points here: tell the person which DNS records to add (from `records`, with each one’s note), then check with list_domains. Live domains get a certificate on their own.

Stop serving an app at one of its custom domains. Visitors to that domain stop reaching the app straight away. Ask the person first.

The workspace’s platform domain, if it has one: apps given a slug answer at <slug>.<domain>. Includes the DNS record the domain needs (one wildcard CNAME) and whether it’s set up.

Give the workspace a platform domain, like apps.example.com, so each app can answer at <slug>.<domain> (set the slug with set_app_slug). The person must add the wildcard DNS record in the result. Changing it moves every app’s platform address to the new domain at once, so ask the person first. Workspace keys only.

Remove the workspace’s platform domain. Every app stops answering at its <slug>.<domain> address straight away (custom domains and its own address keep working). Ask the person first. Workspace keys only.

Give an app its platform address, <slug>.<the workspace’s platform domain>, replacing any slug it had. If it already had one, its old address stops working at once, so ask the person first. Needs a platform domain (set_platform_domain). Slugs are unique within the domain.

Upload an app’s code and/or static files and make them live (the app needs compute). `files` maps module paths to source text; `main` is the ES module whose default export has a fetch(request, env) handler. `assets` maps static file paths (index.html, css/site.css) to their text, served at those paths before the code; a static site needs only `assets`. Text files only here (binary files need the API or SDK). Bindings: env.<NAME> for each database, bucket, email service and variable, and env.ASSETS for the static files.

Make a sandbox’s built output live, without reading the files back. For a build that wrote a wrangler config (TanStack Start and other @cloudflare/vite-plugin apps write dist/server/wrangler.json), give just `wrangler_config`: the code, its entry, the static files and the compatibility flags come from it. Otherwise `assets_folder` is the static files (e.g. "dist") and `code_folder` + `main` the bundled code; everything in code_folder is code, even under an assets/ folder. Binary files are fine. If the code fails to start, the deploy is refused with the error and the app keeps its previous code. Use this instead of deploy after building in a sandbox. Costs nothing beyond the sandbox’s own running time.

An app’s deployments, newest first; the active one is live.

One deployment: whether it’s live, why it failed, its code and file counts, and where it came from (a GitHub commit, a sandbox’s folder, or an upload).

Make an earlier deployment’s code live again, as a new deployment.

An app’s scheduled runs: each cron expression (UTC) in plain words, when it runs next, and how its last run went (ok, error with the reason, or skipped while the app was paused).

Replace an app’s scheduled runs (up to 5; [] removes them all). Each calls the app’s code’s scheduled(controller, env, ctx) handler, like Cron Triggers: five-field cron in UTC, e.g. "0 9 * * *" every day at 9:00, "*/15 * * * *" every 15 minutes, "0 8 * * 1-5" weekdays at 8:00. The code must export a scheduled handler. Each run costs what a request to the app costs.

An app’s recent logs (kept 7 days): a line per request with its status and time taken, what its code printed (console.log, console.error…), and uncaught errors with their stack. Use it to see why something failed. Shows up to `limit` lines, oldest first; narrow with `level: "error"`, `search` or `since`. Free.

An app’s settings and secrets. Secret values are never shown.

Add or change a setting the app’s code reads as env.<NAME>. Secrets (the default) can’t be read back.

Remove a setting or secret from an app.

Read from one of an app’s databases (SQLite): SELECT, WITH … SELECT, EXPLAIN or a reading PRAGMA like table_info. Nothing is changed; SQL that would change data is refused (use execute_sql for that). Several statements are allowed; each returns columns and rows (at most 1,000). Works with read-only keys.

Run SQL that changes one of an app’s databases (SQLite): create or alter tables, migrate, insert, update or delete rows. For reading, use query_database. Several statements are allowed; each returns columns and rows (at most 1,000).

Apply schema migrations to one of an app’s databases, in order, each once: applied names are kept in a d1_migrations table as Wrangler keeps them, so pass every migration each time (like 0001_init.sql, 0002_add_orders.sql) and only new ones run. The first failure stops the run with its error; the ones before it stay applied. Check with the person first: migrations can drop tables.

The migrations applied to one of an app’s databases so far (from its d1_migrations table), oldest first.

A link that downloads a copy of one of an app’s databases as a SQL file (tables, rows, indexes, views), valid 15 minutes without a key. Give it to the person, or fetch it yourself only if you need the contents. Free. Load a copy into an empty database with execute_sql or the import API.

Files in one of an app’s buckets.

A file from a bucket: its text, or base64 for binary files. Files over 1 MB get a download link instead.

Save a file to a bucket, replacing any file with the same key.

Delete a file from a bucket.

A short-lived link to download (GET) or upload (PUT) one file directly, e.g. to hand to a browser.

Send an email through one of the app’s email services: from the app’s own address, or (once the service has a verified sender domain) from an address there with `from`. Costs $0.35 per 1,000 emails, from the balance.

Start a sandbox: an isolated Linux machine with Node, pnpm and git, to write files into and run any code in. The app needs the "sandbox" service. Billed by size while running; it sleeps when idle, keeping its /workspace files (installed packages included) for next time. Give setup_command to install things when it starts. Hourly prices: lite (Tiny) $0.0073 an hour, basic (Small) $0.028 an hour, standard-1 (Medium) $0.074 an hour, standard-2 (Large) $0.129 an hour, standard-3 (Extra large) $0.22 an hour, standard-4 (Huge) $0.401 an hour, the same for either image. Tell the person the rate before starting one. If the result has a local_note (local development only), tell the person: local sandboxes aren't isolated from their machine.

Change a sandbox’s setup command (used from its next start) or how its previews work (at once, no restart): make them public or private, add a script to every preview page, keep access in the address instead of a cookie, or say which sites may show them in a frame. Check with the person first: these change who can open its previews and what runs in them.

An app’s sandboxes and whether each is running.

Run a shell command in a sandbox and wait for it: exit code, stdout and stderr. Commands run in /workspace. It's stopped after 45 seconds (timeout_ms, at most 55), because MCP clients give up on a tool at about a minute; you then get what it printed so far and stopped: true. For anything longer (installs, builds, servers) use sandbox_start_process and check on it with sandbox_process.

Write files into a sandbox, creating folders as needed: path → text, or path → { content, encoding: "base64" } for binary files (images, fonts, models). Up to 2 MB per call. For bigger or many binary files, save them to a bucket and use copy_files_to_sandbox, which never passes them through you. A running dev server picks the changes up.

A file’s text from a sandbox.

What’s in a folder of a sandbox (default: /workspace).

Copy files from one of the app’s buckets into a sandbox (all under `prefix`), keeping their paths below it. Binary files are fine and nothing passes through you. At most 1,000 files and 50 MB.

Save a file or folder of a sandbox to one of the app’s buckets, under `prefix`, keeping paths below the folder; files with the same keys are replaced. Binary files are fine and nothing passes through you. At most 1,000 files and 50 MB.

Start a long-running program in a sandbox (a dev server), in the background, replacing one with the same name. Check it with sandbox_process.

Whether a sandbox process is running, and its recent output.

Stop a background process in a sandbox.

The link to a port a sandbox process listens on, to show people. Private previews (the default) get a signed link that works for an hour, and its token: ask again for a fresh one (a page showing the preview in a frame can hand the token to it by postMessage, { type: "ocp-preview-token", token }, to renew without reloading). url is null until previews are set up on this server.

Start a stopped or asleep sandbox again: its saved files put back (unless it was made with keep_files false), same size and variables. It’s billed while running again, so tell the person first. A running sandbox is left as it is.

Stop a sandbox so it costs nothing. Its /workspace files are saved and come back when it starts again (installed packages don’t, unless it keeps dependencies; sandboxes made with keep_files false start empty).

Delete a sandbox for good.

The workspace’s prepaid balance in USD, and whether it is low, out of credit or paused.

Today’s prices for everything, in plain words, by service and provider (usage is charged at the providers’ own prices), plus the fee for adding funds. Check before costly work and tell the person what it will cost.

What has been used and what it cost, between two days (default: this month so far), grouped by meter, app, end_user or day; or over an exact window with since/until (timestamps, up to 31 days), grouped by meter, app, end_user or hour, with latest_recorded_at. Emails count at once, sandbox time within 10 minutes, requests and database/storage use within about an hour. With app_id, just that app (a key scoped to one app always sees its own).

An app’s scoped keys: what each reaches, read-only or not, its spending limit and what it has spent. Never the secret.

Make a key for another agent (a sub-agent) that reaches only this app, or one of its services, read-only if it only needs to look, optionally with a spending limit in USD. The key is shown this once: hand it over, don’t store it. A scoped key can only make keys no broader than itself. If this key has a spending limit, a key that can change things needs a spend_limit no higher than what this key has left, and what it spends counts toward this key’s limit.

Turn a scoped key off straight away; whoever has it is cut off. A scoped key can only revoke the keys it made (and itself). Confirm with the person first.

The addresses this workspace sends events to, each with the events it gets, whether it’s on, and whether deliveries have been failing.

Send this workspace's events to an https address the person controls, so their server hears about them instead of checking. The answer includes the signing secret (whsec_…) once: tell the person to store it as a secret and check each delivery's opencloudport-signature with it (the SDK's verifyWebhook). Events: deployment.succeeded (New code went live on an app.); deployment.failed (A deployment didn’t go live. data.error says why.); email.delivered (An app’s email reached the recipient’s mail server.); email.bounced (An app’s email bounced: the address doesn’t exist or won’t take mail.); email.complained (The recipient marked an app’s email as spam.); email.failed (An app’s email couldn’t be sent or delivered.); balance.low (The workspace balance went below its low-balance warning.); workspace.out_of_credit (The balance reached $0. Apps pause at data.pauses_at unless funds are added.); workspace.paused (The workspace’s apps were paused because it ran out of credit.); workspace.resumed (Funds were added and the workspace’s apps run again.); app.paused (An app was paused. data.paused_by is owner, limit or workspace.); app.resumed (A paused app runs again.); app.limit_reached (An app reached its monthly spending limit (it pauses until next month or a higher limit).); end_user.limit_reached (An end user reached their monthly spending limit; their new work is refused.); sandbox.stopped (A sandbox stopped. data.reason is asleep (idle) or stopped.); domain.active (A custom domain points here and serves the app, with its certificate.); domain.failed (A custom domain couldn’t be set up. data.problem says why.).

Stop sending events to a webhook and forget its delivery log. Ask the person first.

Pause an app: visitors see "This app is paused.", its sandboxes stop, and new sandboxes, emails, builds and deploys are refused. Its data is kept. Only a person (a workspace key) can resume it, so check with them first.

Undo a pause. The app stays paused if its monthly spending limit (paused_by "limit") or the workspace’s balance ("workspace") still holds it. Needs a workspace key.

What an app has spent this month (UTC), its monthly spending limit, and whether it has reached it.

Set or remove an app’s monthly spending limit. At the limit the app pauses until the month turns or the limit is raised. Limits protect the person’s money: only change one when they ask you to. Needs a workspace key.

Your end users this month (everyone with usage tagged end_user, or a limit of their own): what each has spent and the monthly limit that applies. Needs a workspace key.

Give one end user their own monthly limit (null: no limit for them), or put them back on the workspace default (use_default: true). At their limit, new emails and sandboxes tagged with them are refused with end_user_limit_reached; apps keep serving. Only change limits when the person asks. Needs a workspace key.