Embarko

Actions that cannot be undone. Only call this when the user has clearly asked for this specific change, and say what will be lost before you call. Pick one action: - delete_env_var: remove one env var. Its value is gone for good, because values can't be read back. The running app keeps it until the next deploy; to remove it now, call update_app with action "apply_env_vars" afterwards. - delete_domain: detach a custom domain. The domain stops serving the app straight away. - rename_app: change the app's name, which is also its URL (<name>.embarko.app). The old URL stops working and does not redirect. Active custom domains keep working. Afterwards, use the new name in every call and redeploy. If the reply has terminal: false, poll read_app with action "rename_status" and the projectId from the reply. - delete_app: permanently delete the app with its deployments, env vars and domains. There is no backup. confirmAppName must exactly equal appName. Every action needs appName. delete_env_var, delete_domain and delete_app reply with HTTP 204 and an empty body when they succeed.

app_danger_zone

Call any Embarko Deploy API API endpoint for the user and return its response. Look the endpoint up with get_embarko_deploy_api_api_docs first to get its URL, method, headers, query params and body. Load the quickstart-embarko-deploy-api skill first: it explains which tool to use when. Pass the full url with path variables filled in, the method from the docs, the headers the docs list, query params in `query` (not in the url) and the request body in `body`. For the auth header the docs name (Authorization, proxy_auth_token, x-api-key, ...), pass it with an empty value "": the signed-in user's token is filled in automatically. Never put a real or made-up token there; if the docs name no auth header, leave it out and the token is sent as Authorization. If the API needs the user to sign in, they're asked the first time. Returns { status, ok, headers, data }: the HTTP status and the response body, including error details on failure.

call_any_api_of_embarko_deploy_api

Deploy an app or website to Embarko and return its deployment status and live URL. Use when the user wants to deploy, host, publish, launch, put online, or get a public/live link for something they built — or to redeploy after changes. Follow the returned next instruction until the app is live, then share the URL.

deploy_app

Get the Embarko Deploy API API docs, module by module. Call it without arguments to get all the modules: each module's name, its `path` and the endpoints it contains. Call it with `path` set to one module's path to get that module's full API docs: for every endpoint its method, url, headers, query params, path variables, required fields, a request body example and sample responses. Fetch only the module you need, as one module can be large.

get_embarko_deploy_api_api_docs

Quickstart for the Embarko Deploy API API: find any endpoint in the Embarko Deploy API docs and call it for the signed-in user. Load this before any Embarko Deploy API task. Call this to load the full instructions for this skill before doing the task.

quickstart-embarko-deploy-api

Look at an Embarko app without changing anything. Pick one action: - status: is the app live, building, starting, crashed or failed? Pass deploymentId (from update_app rollback or env-var apply) to check that redeploy instead. Repeat until the reply is terminal. - logs: recent output. Use stream "stderr" for crashes. If the last build failed, this returns the build log. - deployments: last 50 deployments, newest first. rollbackTarget: true marks the ones update_app can roll back to. - env_vars: names of the env vars that are set. Values are secret and never returned. - domains: custom domains and whether each is active. - analytics: traffic, errors, latency, CPU and memory. range: 24h, 7d, 30d, 90d or all.

read_app

Search the Embarko documentation with a natural-language question. Returns the most relevant passages with their page URLs.

search_embarko_deploy_api_docs

List or update an app on Embarko Showcase (embarko.ai/showcase), a public, search-indexed gallery of apps built with AI agents. Use only when the person asks to showcase their app; the app must be claimed first. Before calling: check https://ship.embarko.ai/api/public/showcase/apps/<appName> (no auth) - 200 means already listed, so send only fields that change; 404 means new, and tagline + creatorName are required. Draft the listing from the codebase (tagline, description, story, category, tags, builtWith), show it to the person once, confirm creatorName (never assume the repo author), and ask only for what you can't know: profile link, contributor emails, screenshots/demo video, custom HTML, event slug and code. Omit skipped fields - no placeholders, this publishes. The PUT merges: only keys sent change, \"\" clears one. Omit collectionSlug for the public page; set it for an event page (live when the organiser approves, or at once with its submit code). Reply 201 new / 200 updated with status and next: approved = live, give the person the URL in next and offer promotion posts (for Instagram tag @Embarko and invite it as collaborator; if no videoUrl, suggest a short demo video - approved videos can earn 1 year of Embarko Pro); pending = organiser must approve, resend with code to skip; rejected = next has the reason. 404 SHOWCASE_COLLECTION_UNKNOWN = wrong slug. Other 4xx: fix the input, don't retry as is.

showcase_app

Change an Embarko app in ways that can be undone. Pick one action: - set_env_vars: create or update env vars. This merges: vars you don't name are left alone. Saving does NOT reach the running app; pass apply: true to restart it with the new values (no rebuild). Set several vars in one call so the app restarts once. - apply_env_vars: restart the app with the env vars already saved. Use after several separate writes, or after app_danger_zone delete_env_var. - rollback: put a previous successful version back live, with no rebuild. Leave out deploymentId to undo the last deploy; otherwise pick one with rollbackTarget: true from read_app deployments. - register_domain: attach a custom domain the user owns. Show the user the returned DNS record to add at their registrar, then call verify_domain. - verify_domain: check the domain's DNS and activate it if it points at Embarko. If it fails, DNS has usually not propagated yet: retry later rather than registering it again. - submit_feedback: report a platform bug, a missing feature or confusing docs to the Embarko team. set_env_vars, apply_env_vars and rollback return a deploymentId. Poll read_app with action "status" and that deploymentId until terminal is true. Every action needs appName.

update_app