Skip to main content
Glama

runtime_reservations

Destructive

Hold room for many sandboxes, for a window or as standing room; creates in it are never refused for room or limits up to what was booked. create(sandboxes, startsAt?, endsAt?, standing?, snapshots?, forKey?, vcpu?, memoryMiB?, diskMiB?, region?): Book room for many sandboxes at once: sandboxes (1 to 10000), startsAt and endsAt (ISO 8601; up to 24 hours, starting now or within 14 days), and optionally vcpu, memoryMiB, diskMiB (the size you will create, default 2 vCPU / 4096 MiB / 4096 MiB) and region. In the window your sandbox limits rise by what you booked and the room is kept from everyone else, so creates are never no_capacity or quota_exceeded up to it; create as usual, nothing to name. Sandboxes you run bill at the usual per-second rates; booked room none of them uses costs a quarter of the memory rate (unusedRateMicros per GiB-hour, no CPU), at most unusedMaxMicros if nothing runs, and nothing if you cancel at least an hour before the start. Booking needs a balance covering the estimate; with auto top-up on, what you paid more than a week ago counts too. A decline says why, the most that fit, and the nearest window that takes them all. At the end nothing is stopped. Use it before a batch of evals, rollouts or browser runs. Standing room (standing: true) is held from now until you cancel it: for a pool that deletes a sandbox after each use and makes another, so a replacement is never refused up to it. Name its snapshots and the room is held on the servers holding them, where their forks start; forKey keeps it for this key's sandboxes alone. Keep a few more than the pool runs, for deletes still finishing. Room none of its sandboxes uses costs a quarter of the memory rate every hour it is held (unusedPerHourMicros at most), until you cancel. Change its number or snapshots in place with :update. list(limit?, cursor?): This account's room bookings and declines, newest first, each with its window, status, phase (upcoming, active, ended) and what it runs. Pass nextCursor as cursor for older ones. get(id): A room booking by id: its status, window, phase, sandboxes in use now and at most. update(id, sandboxes?, snapshots?): Change standing room in place: sandboxes (how many it holds) or snapshots (new ones of the same size; the room moves to their servers). It moves or grows only when all of it fits now; otherwise nothing changes and the answer says what fits. cancel(id): Cancel a room booking: its room goes back to everyone at once. Sandboxes running keep running.

Input Schema

NameRequiredDescriptionDefault
idNoThe booking's id.
vcpuNoEach sandbox's vCPUs, as you will create them.
limitNoAt most this many, newest first.
actionYes
cursorNonextCursor from the page before.
endsAtNoWhen it ends: after startsAt, at most 24 hours later. Not for standing room.
forKeyNoStanding room only: hold it for this key's sandboxes alone, so the account's other work never takes it. Default: the whole account's.
regionNoThe region; the default region when absent.
diskMiBNoEach sandbox's disk.
standingNoStanding room: held from now until you cancel it, with no startsAt or endsAt. For a pool that deletes a sandbox after each use and makes another.
startsAtNoWhen the window starts: now, or within 14 days. A time within the minute is now. Not for standing room.
memoryMiBNoEach sandbox's memory.
sandboxesNoHow many sandboxes to hold room for now.
snapshotsNoStanding room only: the snapshots its sandboxes fork from. The room is held on the servers holding them, where their forks start, at their size (leave vcpu, memoryMiB and diskMiB out). All of one size.
idempotencyKeyNoOptional: left out, one is made and returned as idempotencyKey. Send it back only to retry this exact call after a temporary error.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, openWorldHint=true) by disclosing the economics and side effects: unused room bills at a quarter of the memory rate, cancellation at least an hour before start costs nothing, a balance covering the estimate is required, declarations of what happens on decline, and that cancelling returns room while running sandboxes keep running and 'at the end nothing is stopped'.

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

Conciseness3/5

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

Content is front-loaded on create, the most important action, but the body is a dense semicolon-chained block of roughly 500 words with repeated material (the unused-room rate is stated twice) and no per-action structure, which makes the list/get/update/cancel guidance hard to scan.

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?

For a 15-parameter, five-action mutation tool with no output schema, the description still explains what each action yields — list returns bookings and declines newest first with window, status, phase and nextCursor; get returns status, window, phase and in-use counts; update and cancel describe their outcomes and failure behavior. Nothing essential to invoking it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 93%, so the schema already documents ranges, defaults and per-field meanings for sandboxes, vcpu, memoryMiB, diskMiB, forKey, snapshots and region. The description restates most of this (1 to 10000 sandboxes, default 2 vCPU / 4096 MiB, 24-hour and 14-day limits) and only marginally adds, so baseline 3 applies.

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?

The opening line states a specific verb and resource — hold/book room for many sandboxes, either for a time window or as standing room — and enumerates the five actions (create, list, get, update, cancel). An agent can tell this apart from runtime_sandboxes_create because the description explains room is booked in advance and creates are then never refused up to the booked amount.

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?

Explicitly says when to reach for it — 'Use it before a batch of evals, rollouts or browser runs' — and gives the condition for standing room (a pool that deletes a sandbox after each use and makes another). It does not name a sibling alternative or state a when-not condition (e.g. single sandbox creation should use runtime_sandboxes_create), so it falls short of full routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.