paraloncloud-rentals
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PARALON_API_KEY | Yes | API key for ParalonCloud Rental API | |
| PARALON_BASE_URL | No | Base URL for the API (default: https://paraloncloud.com/api/v1) | https://paraloncloud.com/api/v1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_gpusA | List GPU nodes available to rent right now, with price per hour, GPU model, VRAM, CUDA compute capability, and country. Rent by the returned node_id. Read-only, no cost. For modern LLM work prefer compute_cap >= 8.9 (FP8). |
| get_balanceA | Get the account's credit balance (rentals are billed per minute against it). Read-only, no cost. |
| create_rentalA | Start renting a GPU. SPENDS CREDITS (per-minute billing) — confirm with the user before calling. Asynchronous: returns a rental_id with status 'pending'. Provisioning + the secure tunnel take ~20-40 seconds. After creating, call get_rental ONCE to fetch the connection URL — it waits internally for startup and returns when ready, so do NOT poll it in a tight loop. DURATION: the rental is open-ended by default (runs until the user stops it with destroy_rental) — use open-ended as the default. When starting one, briefly tell the user it's open-ended and bills per minute until stopped, and that they can set an 'hours' auto-stop cap instead if they prefer; only pass 'hours' when the user asks for a time limit. An idempotency key is generated automatically so accidental repeats don't start a second GPU. |
| get_rentalA | Get one rental's status and connection details (Jupyter URL + token). After create_rental, call this to get the URL. It WAITS internally (up to ~24s) for the rental to finish coming up and returns as soon as it's ready — so you usually only need ONE call, at most two. Do NOT call it repeatedly in a tight loop. Provisioning plus the secure tunnel take ~20-40 seconds total; the URL is ready when connection_pending is false. Read-only. |
| list_rentalsA | List the account's rentals. By default only active ones (what's running and billing). Pass status='all' for full history. Read-only. |
| destroy_rentalA | Stop a rental — stops the GPU and STOPS BILLING. This is the money brake; safe to call twice. Confirm with the user unless they clearly asked to stop it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct resource and action: listing available GPUs, checking balance, creating, retrieving, listing, and destroying rentals. No overlap or ambiguity.
All tool names follow a consistent verb_noun snake_case pattern (list_gpus, get_balance, create_rental, get_rental, list_rentals, destroy_rental). The verbs and nouns are uniform and predictable.
Six tools is well-scoped for a GPU rental service, covering the essential operations without unnecessary bloat. Each tool serves a clear purpose.
The tool surface covers the full lifecycle: browsing available GPUs, checking balance, creating a rental, retrieving connection details, listing rentals, and destroying to stop billing. No critical gaps for the domain.