rent.dev

Resume a sandbox

rent_resume_sandbox

Idempotent

Resumes a paused sandbox with a new timeout (default 300 s), holding its cost first on the key that started it; a short balance answers 402 with top-up links. An API key with a spend limit cannot resume a sandbox another key started (403 forbidden).

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": {
      "sandbox_id": "<sandbox_id>"
    },
    "name": "rent_resume_sandbox"
  }
}

Input Schema

Name	Required	Description	Default
`timeout_s`	No
`sandbox_id`	Yes	Sandbox id (`lse_…`) from rent_create_sandbox or rent_list_sandboxes. It names the sandbox for its whole life and keeps answering rent_get_sandbox, with the final state, after it ends.

Output Schema

Name	Required	Description	Default
`id`	Yes
`wire`	Yes
`state`	Yes
`domain`	Yes
`region`	Yes
`ended_at`	Yes
`metadata`	Yes
`supplier`	Yes
`template`	Yes
`billed_by`	Yes
`cpu_count`	Yes
`memory_mb`	Yes
`account_id`	Yes
`auto_pause`	Yes
`created_at`	Yes
`sandbox_id`	Yes
`started_at`	Yes
`timeout_at`	Yes
`auto_resume`	Yes
`endpoint_id`	Yes
`held_micros`	Yes
`captured_micros`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (which only declare non-read-only, non-destructive, idempotent, open-world), the description discloses billing mechanics — cost is held against the originating key — and two concrete failure modes with status codes (402 with top-up links on low balance, 403 when a spend-limited key tries to resume another key's sandbox). This is exactly the operational context an agent needs before invoking a billable 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?

Two tight sentences with no filler, leading with the action and following with the cost/authorization consequences. The semicolon-heavy clause about 402 is slightly run-on but still readable and information-dense.

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?

An output schema exists so return values need not be explained; what remains — billing hold, timeout default, and the 402/403 failure paths — is covered. For a billable mutation tool this is complete enough to call correctly without further lookup.

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 only 50%: sandbox_id is well documented in the schema, but timeout_s has no schema description. The description compensates by supplying the default (300 s) for the new timeout, which the schema's min/max bounds alone do not convey, though it could also mention units/rationale for the 86400 cap.

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

Purpose4/5

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

States a specific verb and resource ('Resumes a paused sandbox') plus the key nuance of a new timeout, so the agent knows exactly what operation this is. It does not explicitly differentiate itself from the closely-named sibling rent_extend_sandbox, leaving the paused-vs-running distinction to be inferred.

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?

The precondition ('paused sandbox') and the ownership constraint ('an API key with a spend limit cannot resume a sandbox another key started') give clear context for when this call will succeed. It stops short of naming alternatives such as rent_extend_sandbox for sandboxes that are still running.

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

All rent.dev tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?