Skip to main content
Glama
Sign In

Lium GPU Cloud: live GPU prices and rent links

by io.github.Datura-ai
OverviewDiscussionsAdmin

Remove a Lium pod

remove_pod
DestructiveIdempotent

Request pod deletion. Billing stops when accepted; deletion may finish asynchronously (get_pod shows DELETING). Data on the pod is lost. Before calling, read the pod (get_pod or list_pods) and get_balance, then tell the user in your reply, not only in the approval: the pod name and id, its GPU, its price per hour and their current balance, and that data on the pod is lost. Call only after they agree, also when they asked you not to ask; one call per pod.

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": {
      "pod_id": "<pod_id>",
      "pod_name": "<pod_name>"
    },
    "name": "remove_pod"
  }
}

Input Schema

NameRequiredDescriptionDefault
pod_idYesPod id, as list_pods shows it
pod_nameYesThe pod's name as get_pod shows it, the one you told the user

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / pod_name
      Added value: +{
+  "description": "The pod's name as get_pod shows it, the one you told the user",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "pod_id"
-]New value: +[
+  "pod_id",
+  "pod_name"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / pod_id / description
      Previous value: -"Pod id from rent_pod or list_pods"New value: +"Pod id, as list_pods shows it"
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds behavior the annotations cannot: billing stops on acceptance, deletion may complete asynchronously and is observable as DELETING in get_pod, and pod data is lost. That is exactly the context needed before an irreversible 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?

Front-loads the destructive fact and the async/billing consequences before the procedural instructions, which is the right order. However, "data on the pod is lost" appears twice (sentence three and again inside the disclosure checklist), which is slight redundancy in an otherwise tight passage.

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 destructive, asynchronous, confirmation-gated mutation with no output schema, the description covers consequences, observability of the final state, prerequisites, and the user-facing disclosure requirement. Nothing an agent needs in order to call it safely 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 100% and both parameters are documented in-schema (pod_id as shown by list_pods, pod_name as shown by get_pod). The description adds only the requirement that pod_name be the name already told to the user, which is marginal over the schema; the baseline of 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?

Opens with a specific verb and resource ("Request pod deletion") and immediately contrasts with get_pod, which is named as the way to observe the resulting DELETING state. An agent can distinguish this from siblings like list_pods, get_pod, or rent_pod without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition sequence (read the pod via get_pod or list_pods, call get_balance), an explicit confirmation gate ("Call only after they agree, also when they asked you not to ask"), and an explicit frequency limit ("one call per pod"). It names the alternatives and the conditions that select them.

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

All Lium GPU Cloud: live GPU prices and rent links toolsInspect
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