GPU Cloud

Change auto-reload

gpucloud_set_auto_reload

Idempotent

Turns automatic credit reload on/off. Needs canCharge; the reload amount may not exceed the key max single charge, and every reload counts in this key monthly card-charge cap and in the account budget limit. Turning it on (or changing it while on) takes two steps: without confirmationToken returns the settings and a token; call again with the same arguments and the token once the user approved. Turning it off applies at once. Threshold $10-$5,000, amount $25-$10,000 (turning it off may repeat the amount already saved, as gpucloud_get_auto_reload returns it). monthlyCapCad: the most the automatic reloads may charge per calendar month (Montreal time), $25-$100,000, null = no cap, absent = unchanged (200 for a new configuration); once reached, no automatic reload until next month and the user is told. It never limits a manual payment. [SPENDS MONEY] (permission: billing:auto_reload) [Requires a free GPU Cloud account and MCP key]

Input Schema

Name	Required	Description
`enabled`	Yes
`thresholdCad`	Yes
`monthlyCapCad`	No
`reloadAmountCad`	Yes
`confirmationToken`	No	Token returned by the previous call (valid 10 minutes, single use).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedInput schema / properties / monthlyCapCad / anyOf

Previous value: -[
-  {
-    "maximum": 100000,
-    "minimum": 50,
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 100000,
+    "minimum": 25,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / reloadAmountCad / minimum
```
Previous value: -50New value: +25
```

Changed2 schema fields changedOct 25, 2026

changedInput schema / properties / monthlyCapCad / anyOf

Previous value: -[
-  {
-    "maximum": 100000,
-    "minimum": 25,
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 100000,
+    "minimum": 50,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / reloadAmountCad / minimum
```
Previous value: -25New value: +50
```

Changed1 schema field changedOct 11, 2026

addedInput schema / properties / monthlyCapCad

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 100000,
+      "minimum": 25,
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedOct 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond annotations, it discloses critical behavior: the tool spends money, requires canCharge, uses a single-use confirmation token, and has different immediate behavior for turning off. It also explains charge-cap and budget interactions, which are important for a financial mutation tool.

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?

The purpose is front-loaded and the dense detail is mostly necessary for a complex financial tool. However, the long run-on sentences and heavy parentheticals make it less scannable than it could be.

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 complex money-moving operation with no output schema, the description provides enough context to call it correctly: permissions, account requirements, two-step confirmation, parameter ranges, monthly cap behavior, and off-state behavior 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 only 20%, so the description must carry parameter meaning, and it does: it covers enabled, threshold, reload amount, monthlyCapCad null/absent semantics, and confirmationToken usage. Some wording is dense, but all five parameters receive meaningful explanation beyond the schema.

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 description opens with a specific verb and resource: it turns automatic credit reload on/off. It clearly distinguishes this mutation tool from the read-only sibling gpucloud_get_auto_reload by describing configuration changes and two-step confirmation.

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?

It explains the operational flow: turning on or changing while on requires a confirmation token and a second call, while turning off applies immediately. It references gpucloud_get_auto_reload for reading the saved amount, but does not explicitly frame all read/update alternatives.

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?