Skip to main content
Glama
Sign In
deenesjakoruzh
Lizard MCP

Lizard MCP

Official
by lizard-build
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Lizard MCP

An MCP server that lets ChatGPT, Claude and other MCP clients deploy and manage apps, run code in Lizard Sandboxes and work with Lizard Git repositories on Lizard (lizard.build).

Connect it once, then ask your assistant to ship a service, read logs, set secrets, scale replicas, attach a domain, run a script in a sandbox or open a pull request — in plain words.

Connect a client

The server speaks Streamable HTTP at POST /mcp, and stdio for clients that spawn a local process instead (below). A hosted instance runs at:

https://lizard.build/mcp

Every request carries a bearer token. A client that speaks OAuth gets one itself — the server advertises where, so there is nothing to paste. Clients that only send headers use a liz_ API key instead:

lizard keys create my-mcp-key

The dashboard creates the same thing under Sandboxes → Get started → New API key. Either way the key is shown once.

Claude Code

claude mcp add --transport http lizard https://lizard.build/mcp

Claude Code runs the OAuth flow on first use. To skip it and use a key:

claude mcp add --transport http lizard https://lizard.build/mcp \
  --header "Authorization: Bearer liz_your_key"

Cline

Follow the Cline installation guide to connect the hosted server with a bearer token. Use Cline's streamableHttp transport, keep tool approval on, then check the connection with whoami. No local build is needed.

Cursor and other clients configured by JSON

{
  "mcpServers": {
    "lizard": {
      "url": "https://lizard.build/mcp",
      "headers": { "Authorization": "Bearer liz_your_key" }
    }
  }
}

ChatGPT

ChatGPT connects to a URL and runs OAuth itself — no key to paste. It needs developer mode and a registered connection; see Publishing to Codex / ChatGPT below.

Against a local server

Run it as described in the next section, then use http://localhost:3000/mcp in place of the hosted URL.

Check the connection

curl -sS -X POST https://lizard.build/mcp \
  -H "Authorization: Bearer liz_your_key" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Without a token the same call returns 401 and a WWW-Authenticate header pointing at the OAuth metadata. That is the server working, not failing.

Related MCP server: PlugLayer MCP Server

Run it

npm install
npm run build
npm start

For development with reload:

npm run dev

Run it over stdio

npm start serves HTTP. To have a client spawn the server instead, point it at dist/stdio.js:

{
  "mcpServers": {
    "lizard": {
      "command": "node",
      "args": ["/path/to/lizard-mcp/dist/stdio.js"],
      "env": { "LIZARD_TOKEN": "liz_your_key" }
    }
  }
}

A spawned process has no browser to run OAuth in, so the token comes from the environment and binds the process to one user. Without it the server still starts and lists its tools — calling one then returns a message asking for a key.

Configuration

Variable

Default

What it does

PORT

3000

Port to listen on (HTTP only)

PUBLIC_URL

http://localhost:$PORT

The URL clients reach this server on. Sets the OAuth resource identifier, so it must match the real address in production.

PLATFORM_URL

https://lizard.build

The Lizard API this server talks to

LIZARD_TOKEN

—

API key for stdio mode, where there is no OAuth handshake. LIZARD_API_KEY works too.

Tools

Area

Tools

Account

whoami, workspace_list, workspace_create, workspace_delete, project_list, project_create, project_delete, project_pause, project_resume, workspace_pause, workspace_resume, region_list, billing_status, billing_summary

Workspace limits

workspace_limits_get, workspace_limits_set, workspace_resale_pricing_get, workspace_resale_pricing_set

Services

service_list, service_show, service_create, service_set, service_rename, service_delete, service_pause, service_resume, service_sleep_status, service_sleep_set, service_scale, service_get_port, service_set_port, addon_create

Deploys

deploy_redeploy, deploy_restart, deploy_events

Functions

functions_deploy, functions_invoke, functions_logs, functions_list

Templates

template_list, template_show, template_deploy

Logs and metrics

logs_tail, metrics_get

Secrets

secrets_list, secrets_set, secrets_delete, secrets_refs

Domains

domain_attach, domain_verify, domain_delete, domain_owned_list, domain_dns_list, domain_dns_update

Volumes

volume_list, volume_create, volume_resize, volume_delete

GitHub connection

git_connect, git_checkout, git_status

Lizard Git

repo_list, repo_create, repo_show, repo_delete, repo_files, repo_read_file, repo_commit, repo_commits, pr_list, pr_create, pr_show, pr_merge, ci_run_list, ci_run_show

Sandboxes

sandbox_list, sandbox_show, sandbox_create, sandbox_exec, sandbox_read_file, sandbox_write_file, sandbox_list_files, sandbox_delete, sandbox_set_timeout, sandbox_pause, sandbox_resume, sandbox_snapshot, sandbox_snapshot_list, sandbox_snapshot_delete, sandbox_fork, sandbox_expose_port, sandbox_unexpose_port, sandbox_schedule, sandbox_schedule_list, sandbox_schedule_update, sandbox_schedule_run, sandbox_schedule_runs, sandbox_schedule_delete

Config as code

config_apply

Support

support, support_list, support_show, support_reply

Tool names use snake_case (not the MCP spec's permitted dots) to match OpenAI's function-name pattern ^[a-zA-Z0-9_-]{1,64}$, which some ChatGPT/Codex surfaces enforce directly.

Every tool includes a title in both title and annotations.title. Read tools set readOnlyHint: true; all write tools set destructiveHint: true so clients can ask before changing resources. Shell access to app services is unavailable, so the server exposes no service-shell tool. Use sandbox_exec to run commands in Lizard Sandboxes.

Destructive tools — project_delete, workspace_delete, service_delete, secrets_delete, domain_delete, volume_delete, sandbox_delete, sandbox_snapshot_delete, repo_delete, and domain_dns_update with remove — require an explicit confirmation argument, so a client cannot delete anything or run arbitrary commands by accident.

project_delete puts the project's services and databases in trash for 3 days, but deletes its sandboxes, their volumes and snapshots at once.

billing_status is read-only: it shows the plan (Pro at $19/month with $19 of usage included each month, Pro 5x at $99 with $99, Pro 20x at $499 with $499, the trial, prepaid credits until November 1, 2026, or enterprise), the tier and the Billing link. Starting, changing tier, paying for and cancelling Pro happen in the browser. When the account has to pay before it can create something, the tool error gives the platform's sentence with the page to open on its last line, and structuredContent.error carries the code (PAYMENT_REQUIRED), paymentStatus and the links.

What the Lizard CLI has and this server does not

test/parity/cli-coverage.json maps every Lizard CLI command to the tools that cover it, or says why none does. The main gaps, on purpose:

  • lizard up and other commands that read local files: a remote server never sees them. Deploy from a GitHub or Lizard Git repo instead, or commit files with repo_commit.

  • API keys (lizard keys), payments (lizard billing changes), agent credentials (lizard agents): they handle secrets or money and belong in the browser or a terminal.

  • Lizard Git admin (webhooks, branch rules, collaborators, CI secrets and environments, releases, labels, issues): the Lizard CLI and Lizard SDK cover them.

  • Interactive tools: sandbox shell, VNC and desktop streams, live log streams.

Bought domains: an API key can read their DNS records but not change them. Changes (domain_dns_update, domain_attach on a bought domain) need a client connected with OAuth.

Lizard Git

repo_*, pr_* and ci_* reach Lizard Git (lizard.build/git) with the caller's own token, as Authorization: Bearer. Lizard Git refuses API keys with scopes. Every commit is made on the server with repo_commit; there is no clone. To deploy a repository, call service_create with repoUrl set to lizard:owner/name. LIZARD_GIT_URL points the server at another Lizard Git (default <PLATFORM_URL>/git).

Sandbox workflow

Lizard (lizard.build) provides Lizard Sandboxes for short-lived code execution. These resources are separate from app services. Start with project_list, then call sandbox_create with the chosen project and confirm: true. Keep the returned sandboxId for later calls.

{"name":"sandbox_create","arguments":{"project":"YOUR_PROJECT_ID","lifetimeMs":300000,"confirm":true}}

Use sandbox_write_file to write a script, sandbox_exec to run it, and sandbox_read_file to read its results. Finish with sandbox_delete. Create, execute, write, and delete need the user's approval before the client sets confirm: true. The MCP server does not open a confirmation dialog.

Sandboxes use the interpreter template and size small unless template and size say otherwise, with /workspace as the default path. Sizes are mini (1 vCPU / 2 GB; only the base, claude, codex and interpreter templates, no volume), small (2 vCPU / 4 GB), medium (4 vCPU / 8 GB) and large (8 vCPU / 16 GB). They expire after five minutes by default; lifetimeMs accepts 60,000–86,400,000 milliseconds (a day), and sandbox_set_timeout changes it later. Expiry or deletion loses all files except those on an attached volume. Creation uses billed cloud resources. Host files, environment variables, and access tokens stay out of the sandbox.

sandbox_pause saves memory, processes and files and stops the sandbox; sandbox_resume continues it. sandbox_snapshot saves a running sandbox to start new ones from (sandbox_create with snapshotId), and sandbox_fork starts live copies. sandbox_expose_port gives a port an HTTPS URL that carries its access token (other clients send it as X-Lizard-Access-Token). Pause, resume and snapshot wait up to two minutes for the platform to finish.

Commands run as root within the sandbox, default to a 60-second timeout, and accept up to 120 seconds. Cancellation, timeout, or an uncertain command request destroys the whole sandbox to stop remote work. The confirm field covers this loss of files. Use a sandbox created for the task; keep needed files elsewhere first. A normal nonzero exit code preserves the sandbox. Access or input rejection does not delete it. The server never retries commands automatically.

Text reads and writes accept up to 64 KiB of UTF-8. Each output stream is capped at 64 KiB and includes a truncation flag. All paths refer to the sandbox. sandbox_show and sandbox_list help check an uncertain result before retrying. sandbox_delete treats a sandbox that is already gone as a successful no-op.

Service and sandbox metadata responses mask connection credentials, environment values and build-log snippets, including create, update, pause and resume responses. Credential query parameters in URLs are masked too. Values inside environment and connection maps become strings (***), including numeric and boolean values; explicit reveal returns the original values and types. For credentials, call service_show or sandbox_show with reveal: true only when the user asks for them. secrets_list also masks values unless reveal: true is set. Port tools return access credentials when the user asks to expose a sandbox port.

The HTTP server handles each call with its caller's Bearer token, including OAuth tokens and API keys. It keeps no shared sandbox handles or global SDK credentials. A disconnected client must reconnect to delete its sandbox; its finite lifetime remains the cleanup backstop.

Auth

The server speaks OAuth 2.1 as an MCP protected resource (RFC 9728). It holds no secrets of its own: every request carries a bearer token, and Lizard decides whether that token is valid. Both OAuth-issued tokens and liz_ API keys work.

Each request builds a fresh server bound to the caller's token, so one process serves many users without sharing state.

Over stdio there is no OAuth and no per-request token — the key comes from the environment and the process serves one user, as described above.

Tests

npm test        # unit and MCP transport tests, docs and CLI parity checks
npm run typecheck
npm run build
npm run audit:cli   # every Lizard CLI command mapped? (needs the CLI on PATH)

npm run audit:live calls every tool against the real platform: it creates a workspace named mcp-audit-<time>, works only inside it, deletes it at the end and writes a report to audit-report.json. It needs LIZARD_TOKEN (an API key with no scopes) and uses billed resources for about half an hour. Pass --only sandbox,volume to run some groups.

To test real sandbox resources, set LIZARD_API_KEY, LIZARD_PROJECT_ID, and LIZARD_LIVE_TESTS=1, then run npm exec -- vitest run test/live/sandboxes.test.ts. The test uses stdio MCP to create a sandbox, run shell and file tools, check timeout cleanup, and delete it. It uses billed resources; it does not deploy the MCP server.

test/manual/mcp-inspector.md covers end-to-end checks against a stub platform and a live one.

Use it as a package

Every new version in package.json is released on main as @lizard-build/mcp (a GitHub release with the npm pack file attached, see .github/workflows/release.yml). The package exports getServer(token), which builds the MCP server for one caller, and setPlatformUrl(url) for a host that runs it in-process. dragonlabs-platform installs it to serve the tools at https://lizard.build/mcp: to ship a tool change there, bump the version here, then point the platform's server/package.json at the new release.

Deployed instance

Since 2026-11 the hosted server is part of the Lizard platform, at https://lizard.build/mcp: dragonlabs-platform installs this package (see above) and serves it from server/src/routes/mcp.ts. There is no separate service to deploy.

The first address, https://employ-woman-g1q2.us-east-1.onlizard.com/mcp, still works: the platform answers on it with that address as the resource, so connectors added with it keep their sign-in.

Publishing to Codex / ChatGPT

.codex-plugin/plugin.json is in place. This is a hosted remote MCP server (not a bundled stdio one), so it's wired via .app.json + a registered connection, not .mcp.json. That last step needs a human in a real ChatGPT session — it isn't scriptable:

  1. In ChatGPT: Settings → Security and login → Developer mode (turn it on).

  2. Go to ChatGPT Plugins → + → enter the MCP server URL above → complete the connection.

  3. Copy the resulting plugin_asdk_app_... ID from the browser URL.

  4. Add .app.json at the repo root:

    { "app": { "id": "plugin_asdk_app_..." } }

  5. Add "apps": "./.app.json" to .codex-plugin/plugin.json.

  6. Test locally via a marketplace entry (@plugin-creator, or hand-write ~/.agents/plugins/marketplace.json), then submit through the plugin submission portal for public review.

License

MIT

Available Tools

89 tools
addon_createCreate addonA
Destructive
Inspect

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.

Inputs: type (required), region (required), project (required), name.

billing_statusGet plan and billing statusA
Read-onlyIdempotent
Inspect

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.

Inputs: workspaceId.

billing_summaryGet billing summaryB
Read-onlyIdempotent
Inspect

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

Inputs: workspaceId (required).

ci_run_listList CI runsB
Read-onlyIdempotent
Inspect

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.

Inputs: repo (required), pr, branch, status.

ci_run_showShow CI runA
Read-onlyIdempotent
Inspect

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).

Inputs: repo (required), number (required), logs.

config_applyApply bulk configA
Destructive
Inspect

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.

Inputs: config (required), project (required).

deploy_eventsGet deploy historyA
Read-onlyIdempotent
Inspect

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

Inputs: project (required), service (required).

deploy_redeployRedeploy serviceA
Destructive
Inspect

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.

Inputs: project (required), service (required).

deploy_restartRestart serviceA
Destructive
Inspect

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.

Inputs: project (required), service (required).

domain_attachAttach domainA
Destructive
Inspect

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. For a domain bought on Lizard (domain_owned_list) or a subdomain of it, the DNS records are set for you; if that would replace records that point elsewhere, the call refuses and lists them, and force: true replaces them. Otherwise the response lists the DNS records the user must add, then domain_verify.

Inputs: project (required), service (required), port, force, +1 more.

domain_deleteDelete domainB
Destructive
Inspect

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

Inputs: confirm (required), project (required), service (required), hostname (required).

domain_dns_listList DNS recordsA
Read-onlyIdempotent
Inspect

Read the DNS records of a domain bought on Lizard: name (@ for the domain itself), type, value, TTL and MX priority.

Inputs: domain (required).

domain_dns_updateChange a DNS recordA
Destructive
Inspect

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.

Inputs: name (required), action (required), domain (required), ttl, +4 more.

domain_owned_listList bought domainsA
Read-onlyIdempotent
Inspect

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.

Inputs: no named parameters.

domain_verifyVerify domain DNSC
DestructiveIdempotent
Inspect

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

Inputs: project (required), service (required), hostname (required).

git_checkoutSwitch deploy branchA
Destructive
Inspect

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.

Inputs: branch (required), project (required), service (required).

git_connectGet GitHub connect URLA
Read-onlyIdempotent
Inspect

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.

Inputs: no named parameters.

git_statusGet GitHub connection statusA
Read-onlyIdempotent
Inspect

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.

Inputs: project (required).

logs_tailTail logsA
Read-onlyIdempotent
Inspect

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.

Inputs: project (required), service (required), build, level, +2 more.

metrics_getGet metricsA
Read-onlyIdempotent
Inspect

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

Inputs: project (required), range, service.

pr_createOpen pull requestA
Destructive
Inspect

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.

Inputs: head (required), repo (required), title (required), base, +2 more.

pr_listList pull requestsB
Read-onlyIdempotent
Inspect

List pull requests of a Lizard Git repository (state open by default; closed, all).

Inputs: repo (required), query, state.

pr_mergeMerge pull requestA
Destructive
Inspect

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.

Inputs: repo (required), number (required), method, message, +1 more.

project_createCreate projectA
Destructive
Inspect

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.

Inputs: name (required), workspaceId (required).

project_deleteMove project to trashA
Destructive
Inspect

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.

Inputs: confirm (required), project (required).

project_listList projectsA
Read-onlyIdempotent
Inspect

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

Inputs: workspaceId.

project_pausePause projectA
DestructiveIdempotent
Inspect

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.

Inputs: project (required).

project_resumeResume projectA
DestructiveIdempotent
Inspect

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.

Inputs: project (required).

pr_showShow pull requestA
Read-onlyIdempotent
Inspect

Read a Lizard Git pull request with its conversation, head commit, whether it can merge and what branch rules still need (approvals, checks).

Inputs: repo (required), number (required).

region_listList regionsA
Read-onlyIdempotent
Inspect

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

Inputs: no named parameters.

repo_commitCommit files to Lizard GitA
Destructive
Inspect

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/.

Inputs: repo (required), files (required), branch (required), message (required), +3 more.

repo_commitsList repository commitsA
Read-onlyIdempotent
Inspect

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/.

Inputs: repo (required), ref, page, path.

repo_createCreate Lizard Git repositoryA
Destructive
Inspect

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.

Inputs: name (required), readme, private, workspace, +2 more.

repo_deleteDelete Lizard Git repositoryA
Destructive
Inspect

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.

Inputs: repo (required), confirm (required).

repo_filesList repository filesA
Read-onlyIdempotent
Inspect

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/.

Inputs: repo (required), ref, path, recursive.

repo_listList Lizard Git repositoriesA
Read-onlyIdempotent
Inspect

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.

Inputs: owner, query.

repo_read_fileRead repository fileA
Read-onlyIdempotent
Inspect

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/.

Inputs: path (required), repo (required), ref.

repo_showShow Lizard Git repositoryA
Read-onlyIdempotent
Inspect

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.

Inputs: repo (required).

sandbox_createCreate sandboxA
Destructive
Inspect

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.

Inputs: confirm (required), project (required), size, region, +4 more.

sandbox_deleteDelete sandboxA
DestructiveIdempotent
Inspect

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.

Inputs: confirm (required), sandboxId (required).

sandbox_execRun sandbox commandA
Destructive
Inspect

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.

Inputs: command (required), confirm (required), sandboxId (required), cwd, +2 more.

sandbox_expose_portExpose sandbox portA
DestructiveIdempotent
Inspect

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.

Inputs: port (required), sandboxId (required).

sandbox_forkFork sandboxA
Destructive
Inspect

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.

Inputs: confirm (required), sandboxId (required), count, lifetimeMs.

sandbox_listList sandboxesB
Read-onlyIdempotent
Inspect

List Lizard Sandboxes in an explicit project. Use the returned IDs with sandbox tools; these resources are separate from app services.

Inputs: project (required).

sandbox_list_filesList sandbox filesA
Read-onlyIdempotent
Inspect

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/.

Inputs: sandboxId (required), path.

sandbox_pausePause sandboxA
DestructiveIdempotent
Inspect

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.

Inputs: sandboxId (required).

sandbox_read_fileRead sandbox text fileA
Read-onlyIdempotent
Inspect

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/.

Inputs: path (required), sandboxId (required).

sandbox_resumeResume sandboxA
DestructiveIdempotent
Inspect

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.

Inputs: sandboxId (required).

sandbox_set_timeoutSet sandbox lifetimeA
DestructiveIdempotent
Inspect

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).

Inputs: sandboxId (required), lifetimeMs (required).

sandbox_showShow sandboxA
Read-onlyIdempotent
Inspect

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.

Inputs: sandboxId (required).

sandbox_snapshotSnapshot sandboxA
Destructive
Inspect

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.

Inputs: name (required), sandboxId (required), scope.

sandbox_snapshot_deleteDelete sandbox snapshotA
DestructiveIdempotent
Inspect

Permanently delete a saved sandbox snapshot. Sandboxes already started from it keep running. Get the user's approval first.

Inputs: confirm (required), snapshotId (required).

sandbox_snapshot_listList sandbox snapshotsB
Read-onlyIdempotent
Inspect

List the saved sandbox snapshots of a project: ID, name, template, region, size, scope and status.

Inputs: project (required).

sandbox_unexpose_portRemove sandbox port URLA
DestructiveIdempotent
Inspect

Remove the HTTPS URL of a sandbox port; its access token stops working. The process inside keeps running.

Inputs: port (required), sandboxId (required).

sandbox_write_fileWrite sandbox text fileA
DestructiveIdempotent
Inspect

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/.

Inputs: path (required), confirm (required), content (required), sandboxId (required).

secrets_deleteDelete secretsA
Destructive
Inspect

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.

Inputs: keys (required), confirm (required), project (required), service.

secrets_listList secretsA
Read-onlyIdempotent
Inspect

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.

Inputs: project (required), reveal, service.

secrets_refsList variable referencesB
Read-onlyIdempotent
Inspect

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.

Inputs: project (required), service.

secrets_setSet secretsA
DestructiveIdempotent
Inspect

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.

Inputs: values (required), project (required), service.

service_createCreate serviceA
Destructive
Inspect

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 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.

Inputs: name (required), region (required), project (required), envVars, +3 more.

service_deleteDelete serviceA
Destructive
Inspect

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.

Inputs: confirm (required), project (required), service (required).

service_get_portGet container portB
Read-onlyIdempotent
Inspect

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

Inputs: project (required), service (required).

service_listList servicesA
Read-onlyIdempotent
Inspect

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

Inputs: project (required).

service_pausePause serviceA
DestructiveIdempotent
Inspect

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.

Inputs: project (required), service (required).

service_renameRename serviceB
DestructiveIdempotent
Inspect

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

Inputs: name (required), project (required), service (required).

service_resumeResume serviceA
DestructiveIdempotent
Inspect

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.

Inputs: project (required), service (required).

service_scaleScale serviceB
DestructiveIdempotent
Inspect

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

Inputs: project (required), service (required), cpu, memory, +2 more.

service_setSet service build/deploy configB
DestructiveIdempotent
Inspect

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

Inputs: project (required), service (required), force, branch, +9 more.

service_set_portSet container portC
DestructiveIdempotent
Inspect

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

Inputs: project (required), service (required), containerPort (required).

service_showShow service detailsB
Read-onlyIdempotent
Inspect

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

Inputs: project (required), service (required).

service_sleep_setTurn serverless on or offA
DestructiveIdempotent
Inspect

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.

Inputs: enabled (required), project (required), service (required), idleMinutes.

service_sleep_statusServerless statusA
Read-onlyIdempotent
Inspect

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.

Inputs: project (required), service (required).

template_deployDeploy templateA
Destructive
Inspect

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.

Inputs: template (required), projectName (required), workspaceId (required), placeholderValues.

template_listList templatesA
Read-onlyIdempotent
Inspect

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.

Inputs: mine.

template_showShow templateA
Read-onlyIdempotent
Inspect

Read a template's services, addons and required variables before deployment. Pass the ID or slug returned by template_list.

Inputs: template (required).

volume_createCreate volumeA
Destructive
Inspect

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.

Inputs: name (required), project (required), region, sizeGb, +2 more.

volume_deleteDelete volumeA
Destructive
Inspect

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.

Inputs: volume (required), confirm (required), project (required), service.

volume_listList volumesA
Read-onlyIdempotent
Inspect

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.

Inputs: project (required), service.

volume_resizeResize volumeA
DestructiveIdempotent
Inspect

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).

Inputs: sizeGb (required), volume (required), project (required).

whoamiWho am IA
Read-onlyIdempotent
Inspect

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

Inputs: no named parameters.

workspace_createCreate workspaceA
Destructive
Inspect

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.

Inputs: name (required).

workspace_deleteDelete workspaceA
Destructive
Inspect

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.

Inputs: confirm (required), workspaceId (required).

workspace_limits_getRead workspace limitsA
Read-onlyIdempotent
Inspect

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.

Inputs: workspaceId (required).

workspace_limits_setSet workspace limitsA
DestructiveIdempotent
Inspect

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.

Inputs: workspaceId (required), maxDiskGb, maxCpuVcpus, maxMemoryMb, +1 more.

workspace_listList workspacesA
Read-onlyIdempotent
Inspect

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

Inputs: no named parameters.

workspace_pausePause workspaceA
DestructiveIdempotent
Inspect

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.

Inputs: workspaceId (required).

workspace_resale_pricing_getRead resale pricesA
Read-onlyIdempotent
Inspect

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.

Inputs: workspaceId (required).

workspace_resale_pricing_setSet resale pricesA
DestructiveIdempotent
Inspect

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.

Inputs: workspaceId (required), cpu, off, egress, +4 more.

workspace_resumeResume workspaceA
DestructiveIdempotent
Inspect

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.

Inputs: workspaceId (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    Deploy Server
    Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

    TDQS

    A3.5/5.0

    Scored across 89 tools

    Disambiguation4/5

    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.

    Naming Consistency4/5

    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.

    Tool Count1/5

    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.

    Completeness4/5

    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.

    Maintenance

    ActivityActive
    ResponsivenessLimited data

    Resources

    Related MCP Connectors

    Related MCP Servers