Skip to main content
Glama
Sign In
Lizard MCP

Lizard MCP

Official
by lizard-build
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Turn serverless on or off

service_sleep_set
DestructiveIdempotent

Configure a Lizard service to sleep when idle or remain always on. Set an idle timeout in minutes; the service wakes on the next request and preserves memory while asleep.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>",
      "service": "<service>",
      "enabled": "<enabled>"
    },
    "name": "service_sleep_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
enabledYestrue: sleep when idle; false: always on
projectYesProject name, slug, or ID
serviceYesApp or database name or ID
idleMinutesNoMinutes without traffic before it sleeps

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the concrete side effect that makes this destructive — 'turning it on restarts the service once' — plus idle cost, memory preservation, ~1 second wake latency, and that unsupported services return an explanatory error. That is exactly the context an agent needs before committing a destructiveHint mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the trigger condition, then modal behavior, then side effects and eligibility. Four dense sentences with no filler, though the final eligibility sentence is slightly compressed into a run-on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no nested objects, so the description carries the full burden and does: trigger, both modes, idle default and range, restart side effect, cost/latency behavior, eligibility limits, and error reporting are all covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds information the schema lacks: the default of 15 for idleMinutes (the schema declares only min/max, no default) and the semantic contrast between enabled=true (sleep) and false (always on).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (turn on/off serverless sleep) and resource (a Lizard service), and states both modes explicitly, so an agent can distinguish it from service_pause, service_resume and service_sleep_status without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with a clear triggering condition ('when the user wants a service to be serverless or always on') and lists eligibility (one replica and a port, or Postgres/Redis), which implicitly tells the agent when not to use it. It stops short of naming the nearest alternative tools (service_pause vs. sleeping) explicitly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools