Use this when you need to identify the currently authenticated Lizard user, e.g. before asking which workspace or project to act on.

Use this when the user wants to see which Lizard workspaces they belong to, or needs a workspace ID to scope a project lookup.

Use this when the user wants to see their Lizard projects, optionally filtered to one workspace.

Use this when the user wants to create a brand-new empty Lizard project to hold services. Calling this again creates another project, even with the same name — it does not update an existing one.

Use this when the user needs to know which deployment regions are available before creating a service or addon.

Use this when the user wants to see all apps and addons in a Lizard project.

Use this when the user wants details about a single Lizard service (app or addon) — status, config, resource limits.

Use this when the user wants to create a new empty Lizard service, or deploy a GitHub repository as a new service. Omit repoUrl for an empty service you configure later; provide repoUrl to deploy that repo immediately. Calling this again creates another service, even with the same name — it does not update an existing one. A *.onlizard.com domain is assigned automatically, but not until the build finishes and the service boots — this response's domain field will be null right after creation, that is expected, not an error. Do not invent, guess, or predict a hostname to fill that gap. Tell the user the deploy is in progress and the domain isn't assigned yet; poll service_show or deploy_events and report the real domain value once it's non-null.

Use this when the user wants to provision a managed database or storage addon (Postgres, Redis, or S3) in a Lizard project. Calling this again creates another addon, even with the same name — it does not update an existing one.

Use this when the user wants to rename an existing Lizard service.

Use this when the user wants to permanently delete a Lizard service (app or addon). This is destructive and cannot be undone — requires explicit confirmation.

Use this when the user wants to change replica count, CPU, memory, or storage limits for a Lizard service.

Use this when the user wants to know which container port a Lizard app is listening on.

Use this when the user wants to change the container port a Lizard app listens on.

Use this when the user wants to change a Lizard service's build/deploy configuration — source repo, branch, build command, start command, etc.

Use this when the user wants to trigger a new deployment of an existing Lizard service (rebuild and redeploy current source). Returns immediately once the build is triggered — use deploy_events to check progress. Each call starts another build, even if called again immediately.

Use this when the user wants to restart a running Lizard service without rebuilding it. Returns immediately. Each call restarts it again, even if called again immediately.

Use this when the user wants to see recent deploy/build history and current replica status for a Lizard service.

Use this when the user wants to see recent log output from a Lizard service or a specific build. Returns a bounded snapshot, not a live stream.

Use this when the user wants CPU, memory, or network metrics for a Lizard app or addon over a time range.

Use this when the user wants a cost/billing summary for a Lizard workspace, including current usage and live spend.

Use this when the user wants to see environment variables/secrets configured for a Lizard service or project. Values are masked by default; pass reveal:true to see actual values.

Use this when the user wants to set one or more environment variables/secrets on a Lizard service or project. Overwrites existing values with the same key.

Use this when the user wants to remove one or more environment variables/secrets from a Lizard service or project. This is destructive and cannot be undone — requires explicit confirmation.

Use this when the user wants to see the available reference-variable templates (like postgres connection strings) they can inject into another service's secrets.

Every app already gets a *.onlizard.com domain automatically on its first deploy (check service_show's domain field before calling this — do not invent or guess a hostname). Only call this tool when the user explicitly wants to attach their own custom domain (pass hostname), or when service_show shows no domain yet (e.g. the service was created with skipInitialDeploy and never deployed) and they want one generated. Calling this again without hostname generates another subdomain rather than returning the existing one.

Use this when the user wants to verify DNS configuration for a custom domain attached to a Lizard service.

Use this when the user wants to remove a custom domain from a Lizard service. This is destructive and requires explicit confirmation.

Use this when the user wants to switch which branch a Lizard service deploys from, and redeploy it on that branch. Returns immediately once the redeploy is triggered. Each call starts another build, even if called again immediately.

Use this when the user wants to see GitHub connection status and the repo/branch each service in a Lizard project is tracking.

Use this when the user wants to connect their GitHub account to Lizard. Returns an install URL the user must open in a browser themselves — this cannot complete automatically.

Use this when the user wants to run a one-off shell command inside a running Lizard service's container and see its output. Waits for the command to finish. This executes arbitrary code in the user's own infrastructure on their behalf — requires explicit confirmation.

Use this when the user wants to apply a bulk, config-as-code style configuration to a Lizard project in one request (multiple services/addons/secrets at once), rather than changing one field at a time. The config body is passed through verbatim and can overwrite or remove existing fields — prefer the narrower service./secrets. tools for single-field changes.