Loading ToolBench
Typed, constrained MCP server for the Omarchy Nebius plugin. Manage Nebius GPU VMs with constrained tools for capacity viewing, VM lifecycle, project management, and plugin uninstallation.
Server has 21 tools with explicit schemas and descriptions. Naming follows verb_noun convention (list_, create_, delete_, etc.). Most descriptions are present and actionable (50-200 chars), explaining WHAT the tool does and WHEN to use it. However, many parameter descriptions are missing or minimal. Input schemas are well-formed with types, enums, and constraints (e.g., port ranges 1-65535, disk_gib 50-30720). Output schemas are not documented, LLMs cannot predict response structure. Error handling is implicit; no recovery guidance visible. Destructive tools (delete_vm, delete_saved_disk, uninstall_plugin) lack explicit confirmation patterns in descriptions. Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present but not formalized in schema.
Read-only quota check; include project, platform and preset to check project-specific GPU eligibility too.
Open a terminal and SSH into a running VM in a personal project. Existing VMs use configured SSH keys or agent.
Create the previously reviewed billable VM. The agent's write-tool approval is the final user confirmation.
Create a named personal project with its default network in the chosen GPU region. Check quota first; confirm the name and region with the user.
Permanently delete a saved disk after explicit confirmation.
Permanently delete your VM and its reviewed boot disk after explicit confirmation. Cloud audit evidence must identify you as its creator; plugin registration is not required. Secondary disks are kept.
Output schemas not documented. LLMs cannot predict response structure for any tool. Responses likely contain verbose API metadata (audit fields, pagination internals) that dilute signal and waste tokens.
Parameter descriptions are minimal or missing for many tools. E.g., 'refresh' param in list_vms and view_gpu_capacity lacks explanation of what 'live cloud refresh' means or when to use it. LLMs cannot infer parameter semantics from names alone.
Destructive tools (delete_vm, delete_saved_disk, uninstall_plugin) require explicit user confirmation via 'confirmed' boolean parameter, but descriptions do not explain the confirmation protocol or what happens if confirmed=false. Recovery guidance is absent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Save a loopback-only SSH forward that reconnects after login. Ask which application port to forward.
List available public and custom images for chosen machine configurations and a project.
List background operations, their progress, errors and results.
List saved localhost port forwards and connection status.
List visible VMs across personal projects with state, region, GPU, allocation and SSH details. Managed Kubernetes nodes are hidden by default in plugin Settings. Set refresh to retrieve current state.
Pause, resume or remove a saved local port forward.
Prepare a GPU VM plan with preflight checks, chosen allocation and editable name. No automatic stop is scheduled. Does not create cloud resources.
Prepare plugin uninstallation plan with warnings about cloud resources and options for keeping CLI, SSH key and uv runtime.
Reconcile an interrupted launch by its saved request ID. Restore management and the plugin SSH key. Does not schedule stops, create or delete resources.
For a known local JSON or explicit preemptible admission rejection, verify and clear the false block without cloud mutations.
Start a stopped VM in a personal project and wait for its address. Resumes compute billing.
Stop a VM in a personal project. Its disk remains billable.
Execute plugin uninstallation after explicit user approval. Removes local setup, MCP registration and plugin files. Cloud resources are not affected.
List cached GPU types and on-demand/preemptible availability immediately, with snapshot age and refresh status.
Query VM storage configuration and disk details.
Tool names 'recover_launch' and 'repair_rejected_launches' are vague. 'recover_launch' does not clarify whether it resumes a failed creation or restores management. 'repair_rejected_launches' conflates verification and clearing. Ambiguous names cause LLM misselection.
No error handling guidance visible. Tools do not document what errors are retryable, user-fixable, or fatal. E.g., quota exhaustion, network timeout, or permission denial, LLMs have no recovery path.