Loading ToolBench
MCP server for the ParalonCloud Rental API — let an AI agent rent, use, and stop GPUs from code.
Strong tool naming (verb_noun pattern), comprehensive descriptions (avg 250+ chars), and well-structured schemas with proper enums and constraints. All 6 tools have clear, actionable descriptions that guide LLM behavior (e.g., 'SPENDS CREDITS, confirm with user', 'do NOT poll in a tight loop'). Parameters are typed and constrained. However, output schemas are not documented, LLMs cannot see what fields to expect from responses. Error handling is basic (relies on API passthrough). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles.
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.
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.
Get the account's credit balance (rentals are billed per minute against it). Read-only, no cost.
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.
Output schemas not documented. LLMs cannot see what fields list_gpus, get_rental, list_rentals return. This forces agents to guess field names and risks extraction errors.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). create_rental and destroy_rental have clear risk profiles but are not marked with destructiveHint. get_rental and list_gpus are read-only but lack readOnlyHint. Idempotency of create_rental (via auto-generated key) is not annotated.
Error handling relies on API passthrough. Responses include raw API error objects (e.g., {error: 'network_error', message: '...'}) without recovery guidance. LLMs cannot determine if an error is retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
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).
List the account's rentals. By default only active ones (what's running and billing). Pass status='all' for full history. Read-only.
create_rental description mentions 'idempotency key is generated automatically' but does not document the response structure (rental_id, status='pending'). Agents cannot plan the follow-up get_rental call without seeing the schema.
list_rentals accepts status enum but does not document default behavior or response structure (e.g., does it return a list or paginated result?). No pagination parameters (limit, offset) despite potential for large rental histories.