GPU Cloud

Launch a server (spends money)

gpucloud_create_server

Launches a GPU server billed to the account. Requires the confirmationToken of gpucloud_quote_server for exactly these arguments and the key caps. Neither a card nor the automatic reload is required when the credits pay the first hour; the saved card is charged (and then needed) only for missing credits (at least $25, or the automatic reload amount when larger) or a monthly / annual order. Without enough funds (no credit and no usable card, or a cap reached) it returns a tool error with httpStatus 402 and accountAction (code PAYMENT_REQUIRED; BUDGET_CAP_REACHED for a cap) carrying the message and the console link to fix it; the quote itself never carries a payment link. Hourly: the answer carries onFundsExhausted and, when the automatic reload is off, autoReloadWarning. The owner receives an email for every spend. [SPENDS MONEY] (permission: servers:create) [Requires a free GPU Cloud account and MCP key]

Input Schema

Name	Required	Description	Default
`name`	No	Display name of the server.
`cycle`	No	hourly: first hour from credits, then billed per hour. monthly / annual: first month charged to the saved card.	hourly
`region`	No	Region id (gpucloud_list_regions), default canada-montreal.	canada-montreal
`sshKeyId`	Yes	SSH key id (gpucloud_list_ssh_keys).
`productId`	Yes	GPU product id (gpucloud_list_products).
`templateId`	No	Optional one-click template installed at creation (gpucloud_list_templates): jupyter, ollama-openwebui, vllm, comfyui, pytorch.
`templateModel`	No	Model served by the vllm template (gpucloud_list_templates models[].id); default: the first one.
`onFundsExhausted`	No	Hourly servers: what happens when the balance reaches the server threshold and no automatic reload brings it back. HIBERNATE (default): hibernated (its GPU place is kept, hourly hibernation fee), restarted as soon as the balance is back, deleted after 12 h without credit. DELETE: deleted at once, no hibernation fee, data lost. Machines that cannot be hibernated (spot) are always DELETE.
`confirmationToken`	Yes	Token returned by the previous (quote) call, valid 10 minutes, single use.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026

addedInput schema / properties / onFundsExhausted

Added value: +{
+  "description": "Hourly servers: what happens when the balance reaches the server threshold and no automatic reload brings it back. HIBERNATE (default): hibernated (its GPU place is kept, hourly hibernation fee), restarted as soon as the balance is back, deleted after 12 h without credit. DELETE: deleted at once, no hibernation fee, data lost. Machines that cannot be hibernated (spot) are always DELETE.",
+  "enum": [
+    "HIBERNATE",
+    "DELETE"
+  ],
+  "type": "string"
+}

First observedOct 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes far beyond the annotations: discloses billing flow (credits pay the first hour, saved card charged for missing credits or monthly/annual orders), failure behavior (tool error with httpStatus 402, accountAction PAYMENT_REQUIRED / BUDGET_CAP_REACHED, console link), post-call fields (onFundsExhausted, autoReloadWarning), and an owner email per spend. Also states required permission servers:create and the free-account/MCP-key prerequisite. Nothing here contradicts destructiveHint=false, since data loss only occurs under the explicitly opt-in DELETE policy.

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 action and cost implication, then layers prerequisites, payment logic, and error behavior in a single dense paragraph. It is long but nearly every clause carries decision-relevant information; the semicolon-chained sentences make it slightly harder to scan than ideal.

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 9-parameter, money-spending, non-idempotent mutation with no output schema, the description covers prerequisites, billing, error shapes, returned fields, and side effects (owner email). An agent has everything needed to call it correctly or recover from a 402 without further discovery.

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 schema already documents all nine parameters and the baseline is 3. The description adds real meaning beyond it: the token is bound to 'exactly these arguments and the key caps', and the cycle choice drives whether credits or the saved card is charged, which the schema's cycle description only partly conveys.

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 and resource ('Launches a GPU server billed to the account') and immediately ties it to its prerequisite sibling gpucloud_quote_server, so an agent can separate it from quote/create_order/reserve_server without opening schemas. The title's '(spends money)' reinforces the distinguishing trait.

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 states the prerequisite (a confirmationToken from gpucloud_quote_server for exactly these arguments and key caps) and spells out when a card is needed versus when credits suffice. It stops short of naming alternatives such as gpucloud_reserve_server or gpucloud_create_order for other purchasing paths, so it is strong but not a full when/when-not routing guide.

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?