Lizard MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LIZARD_TOKEN | No | Lizard API key (liz_...). Needed to call tools; create one with `lizard keys create`. The server starts and lists its tools without it. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Lizard is a cloud for apps, databases and sandboxes: deploy GitHub or Lizard Git repos as containerized apps, provision managed Postgres/Redis/S3 addons, and manage them (logs, metrics, secrets, domains, scaling, volumes, shell exec); run code in Lizard Sandboxes; host repositories, pull requests and CI on Lizard Git — scoped to the authenticated user's own workspaces and projects.
Sandboxes
Lizard Sandboxes run code in Firecracker microVMs, separate from app services. Use sandbox_create with an explicit project and finite lifetime (default 5 minutes, at most a day; sandbox_set_timeout changes it), then sandbox_exec, sandbox_read_file, sandbox_write_file and sandbox_list_files with its returned ID. Clean up with sandbox_delete when the task ends. These tools do not deploy an app. sandbox_pause keeps memory, processes and files and stops billing for compute; sandbox_resume continues where it stopped. sandbox_snapshot saves a running sandbox to start new ones from (sandbox_create with snapshotId); sandbox_fork starts live copies. sandbox_expose_port gives a port an HTTPS URL that carries its access token. A persistent volume (volume_create, then sandbox_create with volume) keeps files after the sandbox is gone. Creation uses billed resources. Create, execute, write, and delete require confirm:true after the user approves the action. For sandbox_exec, approval includes destruction of the whole sandbox if cancellation, timeout, or a failed request requires cleanup. Never use it on a sandbox whose files the user needs to keep. A failed request can have side effects; inspect the sandbox before retrying. Keys stay in the MCP server and each request uses only the current caller's access token.
Mental model
workspace -> project -> service (app or addon)
Most tools take a "project" (name/slug/ID) and a "service" (name/ID) param. If unsure which project/service the user means, call workspace_list / project_list / service_list first rather than guessing — resolution is by exact name match, not fuzzy.
Domains — do not guess a hostname
Every app is assigned a *.onlizard.com domain automatically, but not until its build finishes and it boots — this can take anywhere from seconds to a few minutes. The "domain" field is null until then, on service_create's response and on service_show alike. A null/empty domain right after creating or redeploying a service is normal, not an error — it does NOT mean a domain wasn't assigned, only that it isn't assigned yet.
Never fabricate, guess, or predict what the hostname will look like, even as a placeholder — a plausible-looking fake domain is worse than no domain, because the user may try to use it. If the user asks for the domain right after a deploy and it's still null, say the deploy is still in progress and the domain will be available once it finishes; poll service_show or deploy_events and report back the real value once "domain" is actually non-null. Only call domain_attach when the user explicitly wants to bring their own custom domain (pass hostname), or when service_show shows no domain after the deploy has actually finished — e.g. the service was created with skipInitialDeploy and never deployed.
Regions — do not guess a code
Region codes are opaque platform identifiers, not something to infer from a place name. Call region_list before service_create or addon_create if you don't already know a valid code from earlier in the conversation.
Secrets: scope and precedence
Two scopes: project-wide ("global", omit the service param) and per-service (pass service). Default to service-scope — global exposes the value to every service in the project, including ones that don't need it. Only use global for genuinely non-secret, provably-shared values (log level, NODE_ENV, feature flags).
Precedence (last wins): addon-issued env < project secrets < project env < app env < app secrets < platform vars. Platform vars (service name, project ID, PORT, public domain) are last and cannot be overridden.
Check secrets_list before secrets_set/secrets_delete to avoid creating a duplicate key or silently shadowing one at a different scope.
Referencing an addon from a service
Addons don't get separate credentials handed to the user — a consuming service references the addon's env vars via ${{.}} in its own secrets (set with secrets_set), resolved at deploy time. Use secrets_refs to see exactly which addon/key combinations are available in a project before wiring a reference. A ref to a missing addon or key silently resolves to an empty string rather than failing the deploy — after wiring one, it's worth confirming the consumer actually received a value (e.g. via logs_tail, or a page of the app that shows it) rather than assuming success.
What triggers a rebuild vs. just a restart
deploy_redeploy, git_checkout, or a push to the tracked branch: full rebuild.
service_set on build-affecting fields (repoUrl, branch, sourceType, buildCommand, dockerfilePath, rootDirectory): auto-rebuilds — do not also call deploy_redeploy right after, that queues a redundant second build.
service_set on runtime-only fields (startCommand, preDeployCommand, containerPort, watchPatterns): no auto-rebuild — follow with deploy_redeploy to apply.
secrets_set / secrets_delete: applied live, service restarts to pick them up, no rebuild needed.
Pausing instead of deleting
service_pause / project_pause / workspace_pause stop services without deleting anything: each scales to 0 (app URL answers 503, database refuses connections) and keeps its URL, database host, port, password, settings and volumes. Resume with *_resume; the service starts again from the same image with its data. Prefer this over service_delete when the user wants to stop paying for something they may want back.
A paused service is not restarted or redeployed (those return an error) until resumed.
project_delete puts services and databases in trash for 3 days, but deletes the project's sandboxes, their volumes and snapshots at once. Say so before asking.
service_sleep_set makes a service serverless (sleeps when idle with its memory saved, wakes in ~1 s on the next request) or always on. Unlike pause, a sleeping service wakes by itself.
Lizard Git
Lizard Git (lizard.build/git) is Lizard's own git hosting. repo_* tools read and change its repositories (every commit is made on the server with repo_commit; there is no clone), pr_* tools handle pull requests, ci_* tools read CI runs and logs. The git_* tools are about a service's GitHub connection, not Lizard Git. To deploy a Lizard Git repo, call service_create with repoUrl lizard:owner/name. Lizard Git refuses API keys with scopes.
Workspace limits
A workspace owner can cap running sandboxes, CPU, memory and disk (workspace_limits_set). A call that fails with WORKSPACE_SANDBOX_LIMIT or WORKSPACE_USAGE_LIMIT will fail the same way on retry: read workspace_limits_get, then pause or delete a sandbox, scale a service down, or ask the owner to raise the limit.
Writes are immediate and real
There is no separate platform-side confirmation step — a tool call is the action. Destructive tools (project_delete, workspace_delete, service_delete, secrets_delete, domain_delete, volume_delete, sandbox_delete, sandbox_snapshot_delete, repo_delete) require confirm:true in the call itself since there's no interactive prompt in MCP; still get the user's explicit go-ahead in conversation before setting it. All write tools declare destructiveHint:true so clients can ask before changing resources. Shell access to services is unavailable; use sandbox_exec to run commands in a sandbox.
Composition
Chain the calls a request implies and return one result, not a call-by-call narration. E.g. "deploy this repo" -> resolve/create project -> service_create with repoUrl -> report the assigned domain from the response, once it's ready. "Add a database" -> addon_create -> tell the user the ${{name.KEY}} refs available (from secrets_refs) rather than raw credentials.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| workspace_createA | Create a new workspace when the user asks for one. Check workspace_list first. Each call creates another workspace; retries do not reuse the first one. |
| project_deleteA | Delete a project when its owner explicitly asks. Its services and databases stop and stay in trash for 3 days; its sandboxes, their volumes and snapshots are deleted at once and cannot be recovered. Tell the user both parts before asking. Requires the user's confirmation; do not call this to delete only one service. |
| project_pauseA | Use this when the user wants to stop every service of a Lizard project without deleting anything: each app and database scales to 0, keeping its URL, host, port, password, settings and volumes. Returns what was paused and what was skipped, with why. Undo with project_resume. |
| workspace_pauseA | Use this when the workspace owner wants to stop every service in every project of a workspace without deleting anything (same as project_pause for each project). Owner only. Undo with workspace_resume. |
| project_resumeA | Use this when the user wants to start again the services of a Lizard project that they paused. Services paused by a billing freeze stay paused until the account is paid. Returns what was resumed and what was skipped, with why. |
| workspace_resumeA | Use this when the workspace owner wants to start again everything they paused in a workspace. Owner only. Returns what was resumed and what was skipped, with why. |
| workspace_deleteA | Delete an empty workspace (owner only; not the personal one). The platform refuses while it still has live projects, sandboxes or volumes and says what is left. Requires the user's confirmation. |
| workspace_limits_getA | Use this when the user asks what a workspace may run at once, or a call failed with WORKSPACE_SANDBOX_LIMIT or WORKSPACE_USAGE_LIMIT. Returns limits (maxRunningSandboxes, maxCpuVcpus, maxMemoryMb, maxDiskGb; null = no limit) and usage now (runningSandboxes, cpuVcpus, memoryMb, diskGb). CPU and memory are what the workspace's apps and databases use, measured every ~10 s; disk is what its databases and volumes hold. |
| workspace_limits_setA | Cap what a workspace may run at once (owner only, with a key that has no scopes). A field left out stays as it is; null removes that limit. Past maxRunningSandboxes a sandbox create, fork or resume fails with WORKSPACE_SANDBOX_LIMIT. While CPU, memory or disk use is at a cap, deploys, restarts, scale-ups, new databases and volume growth fail with WORKSPACE_USAGE_LIMIT; running services keep running and data stays. |
| workspace_resale_pricing_getA | Read the prices a workspace's scoped API keys are shown, as multiples of Lizard's (owner only, with a key that has no scopes). Returns enabled and multipliers per resource: cpu, memory, storage (volumes), egress, objectStorage, sandbox. |
| workspace_resale_pricing_setA | For a reseller: set the prices that keys scoped to this workspace (or its projects) see, as multiples from 1 to 100 of Lizard's, per resource. Resources not passed keep their current multiplier; off: true turns resale prices off. Only what scoped keys are shown changes: the owner's dashboard, unscoped keys and the owner's bill keep Lizard's prices. Owner only, with a key that has no scopes. |
| whoamiA | Use this when you need to identify the currently authenticated Lizard user, e.g. before asking which workspace or project to act on. |
| workspace_listA | Use this when the user wants to see which Lizard workspaces they belong to, or needs a workspace ID to scope a project lookup. |
| project_listA | Use this when the user wants to see their Lizard projects, optionally filtered to one workspace. |
| project_createA | 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. |
| region_listA | Use this when the user needs to know which deployment regions are available before creating a service or addon. |
| service_listA | Use this when the user wants to see all apps and addons in a Lizard project. |
| service_showB | Use this when the user wants details about a single Lizard service (app or addon) — status, config, resource limits. |
| service_createA | Use this when the user wants to create a new empty Lizard service, or deploy a repository as a new service: GitHub, or Lizard Git (lizard:owner/name, from repo_list). Omit repoUrl for an empty service you configure later; provide repoUrl to deploy that repo immediately; later pushes or commits to its branch deploy again. 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 |
| addon_createA | 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. |
| service_renameB | Use this when the user wants to rename an existing Lizard service. |
| service_deleteA | 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. |
| service_pauseA | Use this when the user wants to stop a Lizard service (app or database) without deleting it: it scales to 0, its URL answers 503 and a database refuses connections. Its URL, database host, port, password, settings and volumes are all kept, and nothing is billed for compute while paused. Undo with service_resume. |
| service_resumeA | Use this when the user wants to start a paused Lizard service (app or database) again. It comes back from the same image with the same URL, host, port, password, settings and data. Pausing or resuming one that already is does nothing. |
| service_sleep_statusA | Use this when the user asks whether a Lizard service (app or Postgres/Redis database) is serverless, i.e. sleeps when idle: returns enabled, idleMinutes, how many times it slept and woke, and the last error if it could not sleep. |
| service_sleep_setA | Use this when the user wants a Lizard service to be serverless (sleep when idle) or always on. On: with no traffic for idleMinutes (5-1440, default 15) it sleeps with its memory saved, costs almost nothing, and the next request or connection wakes it in about a second. Turning it on restarts the service once. Works for apps with one replica and a port, and for Postgres/Redis databases; the error says why otherwise. |
| service_scaleB | Use this when the user wants to change replica count, CPU, memory, or storage limits for a Lizard service. |
| service_get_portB | Use this when the user wants to know which container port a Lizard app is listening on. |
| service_set_portC | Use this when the user wants to change the container port a Lizard app listens on. |
| service_setB | Use this when the user wants to change a Lizard service's build/deploy configuration — source repo, branch, build command, start command, etc. |
| deploy_redeployA | 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. |
| deploy_restartA | 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. |
| deploy_eventsA | Use this when the user wants to see recent deploy/build history and current replica status for a Lizard service. |
| logs_tailA | 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. |
| metrics_getA | Use this when the user wants CPU, memory, or network metrics for a Lizard app or addon over a time range. |
| billing_statusA | Use this when a tool fails with PAYMENT_REQUIRED, or the user asks about their plan, trial or bill. Returns the account's plan (none, pro, payg = old prepaid credits until November 1, 2026, enterprise), the Pro status (trialing, active, past_due, canceled), trial days and trial credits left, this month's credits used of the included $19 and the overage, the next charge, a pending cancel, an unpaid invoice link, and billingUrl. Pro is $19/month, taxes included, with $19 of credits each month. Starting Pro, paying and cancelling happen in the browser at billingUrl; give the user the link. With workspaceId, reads that workspace owner's plan. |
| billing_summaryB | Use this when the user wants a cost/billing summary for a Lizard workspace, including current usage and live spend. |
| secrets_listA | 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. |
| secrets_setA | 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. |
| secrets_deleteA | 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. |
| secrets_refsB | 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. |
| domain_attachA | Every app already gets a *.onlizard.com domain automatically on its first deploy (check service_show's |
| domain_verifyC | Use this when the user wants to verify DNS configuration for a custom domain attached to a Lizard service. |
| domain_deleteB | Use this when the user wants to remove a custom domain from a Lizard service. This is destructive and requires explicit confirmation. |
| domain_owned_listA | List the domains the user bought on Lizard (lizard.build/domains): domain, status (registered once ready), expiry and whether one points at an app. Needs a signed-in user or an API key with no scopes. |
| domain_dns_listA | Read the DNS records of a domain bought on Lizard: name (@ for the domain itself), type, value, TTL and MX priority. |
| domain_dns_updateA | Change one DNS record of a domain bought on Lizard. set replaces every record with that name and type; add keeps the others (several MX or TXT); remove deletes the records that match name, and type and value when given. Types: A, AAAA, CNAME, ALIAS, MX, TXT, URL301 (redirect), URL (302 redirect), FRAME (masked redirect). To point a name at a Lizard app, use domain_attach instead. Needs a signed-in user: an API key can read records but not change them. Changes reach most resolvers within minutes. Get the user's approval before remove. |
| volume_listA | Use this when the user wants to see persistent volumes. Without service: the project's sandbox volumes — name, id, size (sizeGb), status, region, how much is used (lastUsedBytes), and the sandbox it is attached to, if any. With service: the volume attached to that app and where it is mounted. |
| volume_createA | Create a persistent volume. Without service: a sandbox volume in the project, to attach with sandbox_create's volume (it must be in the sandbox's region); the size defaults to the project's default and must be within its limits. With service: a volume attached to that app at mountPath (default /data), one per app; the app restarts with it mounted and files there survive restarts and redeploys. Volumes are billed for their size until deleted. |
| volume_resizeA | Use this when the user wants a bigger persistent sandbox volume. It grows in place and online: no data is copied and an attached sandbox keeps running. A volume cannot shrink (volume_shrink_unsupported), except an older one, which can if at least 10% of the new size stays free (volume_too_full_to_shrink otherwise). Calling again with the current size is a no-op. Allowed sizes are per project (minSizeGb/maxSizeGb); the server rejects anything outside that range with invalid_volume_size, so do not assume a maximum. Returns the updated volume. grownInSandbox false means the attached sandbox still sees the old size until a sandbox next mounts the volume; sizeEnforced false means the region does not enforce the size as a hard limit. Other error codes: volume_not_resizable, volume_resize_in_progress (retry shortly), volume_not_provisioned, volume_capacity_unavailable (no room on the machine to grow), volume_resize_timeout (size left unchanged; safe to retry). |
| volume_deleteA | Permanently delete a volume and every file on it. Without service: a sandbox volume; one attached to a sandbox can't be deleted, so delete the sandbox first. With service: that app's volume; it is detached first and the app restarts without it. Delete an app's volume before deleting its project: a project in trash keeps it for 3 days. Get the user's approval before calling; this cannot be undone. |
| git_checkoutA | Use this when the user wants to switch which branch a Lizard service deploys from (GitHub or Lizard Git source), and redeploy it on that branch. Returns immediately once the redeploy is triggered. Each call starts another build, even if called again immediately. |
| git_statusA | Use this when the user wants to see the account's GitHub connection status and the repo/branch each service in a Lizard project is tracking. For repositories hosted on Lizard Git use repo_list / repo_show. |
| git_connectA | Use this when the user wants to connect their GitHub account to Lizard, e.g. to deploy a private GitHub repo. Returns an install URL the user must open in a browser themselves — this cannot complete automatically. Lizard Git repositories need no connection. |
| config_applyA | 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. |
| template_listA | Find published app templates to deploy. Set mine to list your own templates, including private ones. Use template_show to inspect required variables before deploying. |
| template_showA | Read a template's services, addons and required variables before deployment. Pass the ID or slug returned by template_list. |
| template_deployA | Deploy a template as a new project in the chosen workspace. Read template_show first and supply required placeholderValues. Each call creates another project and may incur charges. Do not retry a partial failure blindly: inspect the returned project first. |
| sandbox_listB | List Lizard Sandboxes in an explicit project. Use the returned IDs with sandbox tools; these resources are separate from app services. |
| sandbox_showA | Read a sandbox's status (running, pausing, paused, resuming, ...), project, template, size and expiry. The platform checks the current user's access to this ID. |
| sandbox_createA | Create a sandbox (a Firecracker microVM) in an explicit project. Uses billed cloud resources and returns its ID. Defaults: template interpreter, size small (2 vCPU / 4 GB), a 5-minute lifetime; expiry deletes its files unless a volume is attached. Other templates: base, codex, claude, opencode, pi, prime, desktop (the server checks the name). Sizes: small, medium (4 vCPU / 8 GB), large (8 vCPU / 16 GB). Pass snapshotId to start from a saved snapshot (it keeps the snapshot's size, so leave size out) and volume to mount a persistent volume. No host files, environment variables, or API key are copied into it. Get the user's approval before creating it; do not retry an uncertain response blindly. |
| sandbox_execA | Run a shell command inside an existing sandbox, as root. Requires the user's approval. Cancellation, timeout, or a failed command request destroys the whole sandbox and all its files to stop remote code. A nonzero command exit code preserves it. Use an ephemeral sandbox created for this task. Output is capped at 64 KiB per stream; do not blindly retry a failed command. |
| sandbox_read_fileA | Read up to 64 KiB of UTF-8 text from a sandbox. Relative paths start at /workspace. Paths refer to the remote sandbox, never the MCP server's files. Uses the Lizard API; docs: https://lizard.build/docs/. |
| sandbox_write_fileA | Write up to 64 KiB of UTF-8 text to a sandbox, replacing an existing file. Requires the user's approval. Relative paths start at /workspace. Does not write to the MCP server's filesystem. Uses the Lizard API; docs: https://lizard.build/docs/. |
| sandbox_list_filesA | List one directory inside a sandbox: name, path, type and size of each entry. Relative paths start at /workspace. Uses the Lizard API; docs: https://lizard.build/docs/. |
| sandbox_deleteA | Permanently destroy one sandbox and all its files (an attached volume stays). Get the user's approval before calling. Use this to clean up a sandbox created for a task. Does not delete its project or any app services. |
| sandbox_set_timeoutA | Change how long a sandbox lives from now: it stops and loses its files (except an attached volume) when the time runs out. Use it to keep a sandbox the user still needs, or to end one sooner. 60,000 ms to 86,400,000 ms (a day). |
| sandbox_pauseA | Save a running sandbox's memory, processes and files, and stop it. A paused sandbox costs only its storage and does not count against the running-sandbox limit. Waits up to 2 minutes for it to finish pausing. Undo with sandbox_resume. |
| sandbox_resumeA | Start a paused sandbox again, where it left off: same memory, processes and files. Waits up to 2 minutes for it to run. If resuming fails, the saved state is kept; try again. |
| sandbox_snapshotA | Save a running sandbox, memory and processes included, as a private snapshot to start new sandboxes from (sandbox_create with snapshotId). The sandbox keeps running. scope says where it may be restored: user (any of your projects), workspace, or project. Snapshots are billed for storage until deleted. Waits up to 2 minutes for the snapshot to be ready; a large one may still be processing, so check sandbox_snapshot_list. |
| sandbox_snapshot_listB | List the saved sandbox snapshots of a project: ID, name, template, region, size, scope and status. |
| sandbox_snapshot_deleteA | Permanently delete a saved sandbox snapshot. Sandboxes already started from it keep running. Get the user's approval first. |
| sandbox_forkA | Start live copies of a running sandbox: memory, processes and files. The source pauses for a moment and keeps running. Each copy is a new billed sandbox and counts toward the running-sandbox limits, so near a limit only some may start: the result has one entry per copy, a sandbox or an error. Copies live as long as the source unless lifetimeMs is given. Get the user's approval first. |
| sandbox_expose_portA | Give a port inside a running sandbox an HTTPS URL, e.g. to show the user a web app the sandbox runs (it must listen on 0.0.0.0). The port stays private: the returned url carries an access token, so a browser opens it once and then keeps a cookie; other clients send accessToken in the X-Lizard-Access-Token header. Anyone with the url or token can reach the port, so share it only with the user. Remove it with sandbox_unexpose_port. |
| sandbox_unexpose_portA | Remove the HTTPS URL of a sandbox port; its access token stops working. The process inside keeps running. |
| repo_listA | List Lizard Git repositories (lizard.build/git — Lizard's own git hosting, not GitHub): by default the user's own and the ones they collaborate on. owner narrows to one owner's; query searches names and descriptions. Lizard Git refuses API keys with scopes. |
| repo_createA | Create a Lizard Git repository. Private by default. readme: true starts it with a README (otherwise it is empty until the first repo_commit). workspace (a workspace slug) makes that workspace's members its collaborators. To deploy it, service_create with repoUrl lizard:owner/name; every commit to its branch then deploys. |
| repo_showA | Read a Lizard Git repository's details: default branch, visibility, the user's role, whether it is empty, branch and open issue/pull request counts. |
| repo_deleteA | Permanently delete a Lizard Git repository with its branches, issues, pull requests and CI runs. Services deploying from it stop getting new deploys. Owner or admin only. Get the user's approval first; this cannot be undone. |
| repo_filesA | List a folder of a Lizard Git repository (path, default the root) at a ref (branch, tag or commit; default branch if omitted). recursive: true lists every file path instead. Uses the Lizard API; docs: https://lizard.build/docs/. |
| repo_read_fileA | Read a text file from a Lizard Git repository at a ref (default branch if omitted), up to 64 KiB. Binary or larger files return their size without content. Uses the Lizard API; docs: https://lizard.build/docs/. |
| repo_commitA | Commit changes to a branch of a Lizard Git repository, made on the server (no clone needed): each file is new text content, delete: true, or a rename with moveFrom. createFrom makes the branch from that ref when it doesn't exist yet. With expect (the commit you based the change on), a branch that moved meanwhile is merged by the server and only a real conflict fails (409, with the paths). Pass an idempotencyKey to make a retry safe. A commit to a branch a service deploys from starts a deploy, and to a branch with .lizard/workflows starts CI. Uses the Lizard Git API; docs: https://lizard.build/docs/. |
| repo_commitsA | List recent commits of a Lizard Git repository at a ref (default branch if omitted), optionally only those touching path. Uses the Lizard API; docs: https://lizard.build/docs/. |
| pr_listB | List pull requests of a Lizard Git repository (state open by default; closed, all). |
| pr_createA | Open a pull request in a Lizard Git repository from head (a branch, or owner:branch of a fork) into base (default branch if omitted). draft: true opens it as a draft. |
| pr_showA | Read a Lizard Git pull request with its conversation, head commit, whether it can merge and what branch rules still need (approvals, checks). |
| pr_mergeA | Merge a Lizard Git pull request: method merge (default), squash or rebase; deleteBranch removes the head branch afterwards. The base branch moves, which can start a deploy or CI. Get the user's go-ahead first. |
| ci_run_listB | List recent CI runs of a Lizard Git repository (workflows in .lizard/workflows, GitHub Actions syntax), newest first; filter by branch, pull request number or status. |
| ci_run_showA | Read one CI run of a Lizard Git repository with its jobs and steps. logs: true adds each job's log (the last 64 KiB of each, where failures usually are). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 89 tools
The tools are mostly clearly separated by resource and action, with descriptions that explain scope differences such as service vs project vs workspace pause/resume/delete. A few areas still invite confusion, especially deploy_redeploy vs deploy_restart vs git_checkout, service_pause vs service_sleep_set, and config_apply vs narrower service/secrets tools, but the descriptions generally resolve the choice.
Names overwhelmingly follow a snake_case resource_action convention, e.g. service_list, project_create, sandbox_resume, pr_merge. There are minor deviations and uneven verb choices such as show vs get, plus outlier names like whoami, but the overall pattern is predictable.
89 tools is far beyond an appropriate surface for an agent-facing server, even for a broad cloud platform. The sheer number creates high selection and context burden, and many capabilities could be grouped into fewer higher-level tools or resource-oriented operations.
The surface covers a very wide platform lifecycle: workspaces, projects, services, addons, deploys, logs, metrics, secrets, domains/DNS, volumes, billing, templates, sandboxes, Git, pull requests and CI. There are still minor lifecycle gaps such as explicit project/workspace get or update operations, PR comments/reviews, and some billing/domain purchase actions, but core workflows are well covered.