Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

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

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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. Stops its services and moves the project to trash for three days. 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.

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_showA

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

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_scaleA

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

service_get_portA

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

service_set_portA

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_summaryA

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_refsA

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

domain_verifyA

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

domain_deleteA

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

volume_listA

Use this when the user wants to see the persistent sandbox volumes in a Lizard project — name, id, size (sizeGb), status, region, how much is used (lastUsedBytes), and which sandbox it is attached to (attachedSandboxId), if any.

volume_resizeA

Use this when the user wants to grow or shrink a persistent sandbox volume. The resize happens in place and online: the size is a filesystem quota, no data is copied, it completes in well under a second, and an attached sandbox keeps running. Both growing and shrinking are allowed, but a shrink must leave at least 10% of the new size free — check lastUsedBytes in volume_list first and pick a size comfortably above it. Calling again with the current size is a no-op. Allowed sizes are per-project (minSizeGb/maxSizeGb from GET /api/projects/:projectId/volume-limits); the server rejects anything outside that range with invalid_volume_size, so do not assume a maximum. Returns the updated volume plus sizeEnforced (whether the quota is actually enforced on the backing storage). Error codes: invalid_volume_size, volume_not_resizable, volume_too_full_to_shrink (choose a larger size), volume_resize_in_progress (retry shortly), volume_not_provisioned, volume_capacity_unavailable (not enough room on the node to grow), volume_resize_timeout (size was left unchanged; safe to retry).

git_checkoutA

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.

git_statusA

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

git_connectA

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.

ssh_execA

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.

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, project, template, and expiry. The platform checks the current user's access to this ID.

sandbox_createA

Create an ephemeral interpreter sandbox in an explicit project. Uses billed cloud resources and returns its ID. The default lifetime is 5 minutes; expiry deletes its files. 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.

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.

sandbox_deleteA

Permanently destroy one sandbox and all its files. 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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 56 tools

Disambiguation4/5

Tool purposes are mostly distinct, with clear resource/action prefixes such as service_pause vs project_pause vs workspace_pause, and deploy_redeploy vs deploy_restart. A few boundaries are softer — service_set vs service_scale vs service_set_port/config_apply, billing_status vs billing_summary, and sandbox_exec vs ssh_exec — but the detailed descriptions help differentiate them.

Naming Consistency4/5

Names consistently use snake_case and a resource_action pattern, making the set predictable. Minor deviations like whoami, billing_summary/billing_status, and service_sleep_status/service_sleep_set break the verb-action pattern slightly but remain readable and coherent.

Tool Count2/5

56 tools is excessive for a single MCP server; many granular operations (service_get_port, service_set_port, service_sleep_status, service_sleep_set) could be folded into broader tools. While the platform is broad, the count far exceeds typical coherence thresholds (3–15) and makes discovery and selection costly.

Completeness4/5

Core lifecycle coverage is strong for services, secrets, domains, deploys, sandboxes, and templates, with config_apply filling bulk-operation gaps. Minor gaps remain — e.g., no workspace_delete, no explicit volume_create/delete/attach, and limited addon-specific update tools — but agents can likely work around them.

Maintenance

ActivityActive
ResponsivenessUnresponsive