Loading ToolBench
MCP server exposing Lizard PaaS platform to ChatGPT and other MCP clients
Lizard MCP demonstrates solid tool definition quality with consistent naming conventions, comprehensive descriptions, and proper schema validation. All 29 tools follow verb_noun naming patterns (workspace_list, service_create, deploy_redeploy, etc.). Most tools have substantive descriptions (100-300 chars) that explain WHEN to use them and what they return. Input schemas are well-formed with type definitions and parameter descriptions. However, there are notable gaps: several tools lack complete input schema documentation (6 tools have minimal/missing schemas), some parameter descriptions are generic, and output schemas are not formally documented. Error handling is present but could be more specific about recovery paths. The server uses tool annotations (toolAnnotations=true) which is a current-spec positive. Token conservation is good, descriptions are concise and avoid example values.
Create a managed addon (Postgres, Redis, S3) in a Lizard project.
Use this when the user wants a cost/billing summary for a Lizard workspace, including current usage and live spend.
Use this when the user wants to 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.
Use this when the user wants to see recent deploy/build history and current replica status for a Lizard service.
Use this when the user wants to 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.
Six tools (service_create, service_show, service_list, service_set, addon_create, ssh_exec) lack visible input schema documentation. The source code does not show explicit JSON Schema parameter definitions for these tools, only descriptions in the provider code.
Output schemas are not formally documented for any tool. The server returns structured JSON via the `ok()` helper, but there is no published schema or field documentation describing the shape of responses. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Tool descriptions for service_create, service_show, service_list, service_set, addon_create are minimal (50-70 chars) and lack context about WHEN to use them vs similar tools or what prerequisites exist. Descriptions should be 100-300 chars to guide LLM selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
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.
Every app already gets a *.onlizard.com domain automatically on its first deploy (check service_show's `domain` field before calling this — do not invent or guess a hostname). Only call this tool when the user explicitly wants to attach their own custom domain (pass hostname), or when service_show shows no domain yet (e.g. the service was created with skipInitialDeploy and never deployed) and they want one generated. Calling this again without hostname generates another subdomain rather than returning the existing one.
Use this when the user wants to remove a custom domain from a Lizard service. This is destructive and requires explicit confirmation.
Use this when the user wants to verify DNS configuration for a custom domain attached to a Lizard service.
Use this when the user wants to switch which branch a Lizard service deploys from, and redeploy it on that branch. Returns immediately once the redeploy is triggered. Each call starts another build, even if called again immediately.
Use this when the user wants to connect their GitHub account to Lizard. Returns an install URL the user must open in a browser themselves — this cannot complete automatically.
Use this when the user wants to see GitHub connection status and the repo/branch each service in a Lizard project is tracking.
Use this when the user wants to see recent log output from a Lizard service or a specific build. Returns a bounded snapshot, not a live stream.
Use this when the user wants CPU, memory, or network metrics for a Lizard app or addon over a time range.
Use this when the user wants to create a brand-new empty Lizard project to hold services. Calling this again creates another project, even with the same name — it does not update an existing one.
Use this when the user wants to see their Lizard projects, optionally filtered to one workspace.
Use this when the user needs to know which deployment regions are available before creating a service or addon.
Use this when the user wants to remove one or more environment variables/secrets from a Lizard service or project. This is destructive and cannot be undone — requires explicit confirmation.
Use this when the user wants to see environment variables/secrets configured for a Lizard service or project. Values are masked by default; pass reveal:true to see actual values.
Use this when the user wants to see the available reference-variable templates (like postgres connection strings) they can inject into another service's secrets.
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.
Create a new Lizard service (app or addon) in a project.
Delete a Lizard service permanently. This is destructive and requires explicit confirmation.
List all services (apps and addons) in a Lizard project.
Update one or more fields on a Lizard service configuration.
Get detailed configuration and status for a Lizard service.
Execute a shell command inside a running Lizard service container and return output.
Use this when you need to identify the currently authenticated Lizard user, e.g. before asking which workspace or project to act on.
Use this when the user wants to see which Lizard workspaces they belong to, or needs a workspace ID to scope a project lookup.
Error handling is present (via the `handle()` wrapper in tool-helpers.ts) but error messages are generic. They lack recovery guidance, e.g., a 'not found' error should suggest calling a discovery tool first. See pattern:recovery-guide.
ssh_exec tool description (75 chars) is too brief and lacks safety warnings about arbitrary command execution. Should explicitly state 'runs shell commands inside the service container, only use for commands the user recognizes and approves.'
No pagination or result-limiting parameters visible on list tools (workspace_list, project_list, service_list, region_list). If these can return large result sets, capping results and offering pagination is critical to prevent context window exhaustion.