GPU Cloud

Reserve a GPU (automatic launch when back in stock)

gpucloud_reserve_server

Reserves a GPU machine that is out of stock: GPU Cloud launches the server AUTOMATICALLY as soon as it is back (machines are gone in 1 to 2 minutes), before other customers (first come, first served per machine). Requires a saved credit card (else httpStatus 402 PAYMENT_REQUIRED with the card link: an AI never enters card details), the user's explicit agreement (consent: true) and a maximum hourly price. The automatic reload is not required: the answer carries onFundsExhausted (the action at the threshold, chosen with the onFundsExhausted argument) and, when the reload is off, autoReloadWarning (show its message to the user). At launch, if the balance does not cover the first hour plus the hibernation threshold, only the missing amount is charged to the saved card; then the server is billed by the hour. Nothing is charged when reserving. [SPENDS MONEY] (permission: servers:reserve) [Requires a free GPU Cloud account and MCP key]

Input Schema

Name	Required	Description
`name`	No	Server name (letters, digits, space, dot, dash, underscore).
`consent`	Yes	true ONLY once the user explicitly agreed to: "I authorize GPU Cloud to launch this server as soon as it is available, to charge my saved card the amount needed if my balance is not enough, then to bill it by the hour under the terms." (version 2026-10-10). Without it nothing is reserved.
`sshKeyId`	Yes	SSH key id installed on the server (gpucloud_list_ssh_keys).
`productId`	Yes	Exact GPU machine to reserve (model and size, gpucloud_list_products), e.g. one shown out of stock.
`templateId`	No	Optional one-click template installed at launch (gpucloud_list_templates).
`maxHourlyCad`	Yes	Highest hourly price (CAD) the user accepts: at least the current price (gpucloud_get_product), at most 5 times it. Above it at launch time, the reservation waits.
`validityDays`	No	Days the reservation stays valid (1 to 30, default 7); renewable in the console.
`templateModel`	No	Model served by the vllm template.
`onFundsExhausted`	No	What happens to the launched server when the balance reaches its threshold: HIBERNATE (default: kept 12 h with an hourly hibernation fee, restarted when the balance is back) or DELETE (deleted at once, data lost). Spot machines are always DELETE.
`acceptAlternative`	No	true: an equivalent machine (same usage, at least the same GPU memory, never spot) may be launched when the exact one is not in stock. Default false: this exact machine only.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses the 402 PAYMENT_REQUIRED path with card link, that an AI must never enter card details, consent requirement and wording, that nothing is charged at reservation time, the partial-charge behavior at launch, the onFundsExhausted / autoReloadWarning return fields, and flags [SPENDS MONEY] with the required permission. Annotation-consistent (readOnlyHint=false) and richly behavioral.

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-loads the core differentiator (out-of-stock reservation with automatic launch) and keeps everything in two dense paragraphs. The many parentheticals and trailing disclosure clauses make it heavy, but each sentence carries operational information rather than filler.

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?

With no output schema, the description compensates by describing the returned fields (onFundsExhausted, autoReloadWarning) and the full billing/consent flow. Prerequisites, spend implication and permission are all present, leaving nothing needed for a correct call.

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 100%, so all ten parameters are already documented in the schema, including consent wording, maxHourlyCad bounds and onFundsExhausted semantics. The description mostly echoes those constraints (consent, max hourly price) rather than adding new per-parameter meaning, so the baseline 3 is appropriate.

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?

States a specific verb (reserves) on a specific resource (a GPU machine that is out of stock) and describes the distinctive automatic-launch behavior. An agent can separate this from gpucloud_create_server (immediate launch) or gpucloud_list_reservations without opening any 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?

Gives clear context for when this applies (machine out of stock, launch on restock, first-come-first-served) and lists prerequisites: saved credit card, explicit consent, maximum hourly price. It does not explicitly name the sibling alternatives such as gpucloud_create_server for an in-stock machine, so it falls short of the top band.

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

All GPU Cloud 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?