Apps

This is the surface that actually hosts something. You hand agenthost your project source inline and it builds and runs it on managed hosting with automatic HTTPS and routing — no build config, no containers, no ports. What each runtime expects from that source is Runtimes; this page is the tool contract around it. For the task-shaped version, see Put an app online.

create_app

Provision an app (Node, PHP, Python, or a static site) inside a project. Pass files and it builds and deploys in the same call.

Each entry in files is { path, content, encoding } — a project-relative path with no leading slash or .., the file's content, and an optional encoding of utf8 (the default) or base64 for binary assets.

For a project too large to pass inline, mint a ticket with begin_upload, stream a tarball to it, and pass the resulting upload_id here instead — the runtime is inferred from the uploaded tree exactly as it would be from files. See Sending a large project.

fqdn is settled here and cannot be changed afterwards: there is no tool for moving an app to another hostname, so to change it, create the app again and delete the old one. env is not — manage_env covers adding, changing and removing variables later.

Use env only for values the customer has already told you. A real secret should not come through this call: an API key passed here has been in the conversation, in the model's context, and through an MCP client that agenthost does not run. Call manage_env instead and let them type it in themselves.

The customer does not need to own a domain. Omit fqdn and agenthost assigns a free hostname; only pass it when the customer is bringing their own, in which case the result includes the DNS record they must add. Relay those steps to them — HTTPS is provisioned automatically once DNS resolves.

deploy_app

Build and run new source for an app that already exists. The files you pass replace the app's prior content wholesale.

Exactly one of files or upload_id is required.

list_apps

List your apps, optionally filtered to one project.

get_app

Fetch a single app by id, refreshing and returning its live build/run status. This is the tool to poll after a deploy.

The result carries the app's URL, runtime, status, the names (never the values) of its environment variables as envKeys, and a lastDeploy summary. When the app uses a custom domain it also carries the DNS record still needed to point it here.

get_app_logs

Fetch recent build and runtime logs for an app. Best-effort — logs can be briefly unavailable, in which case fall back to hitting the app's URL.

delete_app

Delete an app: tears it down and removes all of its data.

manage_env

Return a link the customer opens in a browser to read, add, change and remove an app's environment variables themselves. This is how a variable is changed after the app was created, and how any secret should be set in the first place.

The result carries the URL and, for a named app, the names currently set. Hand the link over and let them do it — the value never passes through you. Saving there restarts the app so the values take effect, without rebuilding it.

The link grants nothing on its own: they sign in with a one-time code emailed to them, on a session deliberately shorter than the one that authorizes MCP clients. So it is safe to send as-is.

get_env

List an app's environment variables: every name, and the value of only those the customer has marked agent can read in the secrets manager.

Each entry carries key, secret, managed, and value — the last present only when the customer shared it. Everything defaults to secret, including anything agenthost sets itself (an attached database's connection string is managed and never readable).

There is no way to ask for a value that wasn't shared, and no flag that overrides it. If you need one, don't ask the customer to paste it into the conversation — call manage_env and send the link.

See Environment variables.