colab-persist
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| runtime_statusA | Check the configured Colab runtime and Drive mount without provisioning compute. |
| plan_datasetA | Validate a local immutable shard manifest and size a bounded cache for large datasets. Reads only the manifest, not the corpus. Does not provision a VM, contact Drive, or confirm source files, VM free disk, Drive quota, throughput or GPU model fit. Training scripts use colab_persist.datasets.ShardCache on the VM. |
| start_runtimeA | Provision or reuse the configured runtime. Default GPU is L4. Consumes Colab units. If drive_mounted is false, run colab-persist mount in a user terminal to authorize Drive. |
| prepare_workspaceC | Create a managed workspace or restore its latest Drive snapshot on a fresh VM. |
| run_scriptA | Run a local Python script on the active, Drive-mounted GPU VM. Restores previous files, uploads the script (or an explicitly selected source directory), periodically checkpoints, flushes Drive on completion, then stops by default. Script may invoke nvcc and other tools. Only workspace files are saved, not RAM or credentials. Google may still terminate the VM; completed snapshots are recoverable. Can be long-running. |
| list_checkpointsB | List complete checkpoint manifests from the mounted Drive. |
| restore_workspaceB | Restore a verified Drive checkpoint into an empty workspace. Refuses overwrites. |
| save_workspacesA | Checkpoint all managed workspaces, flush Drive, and unmount it. VM stays allocated. Refuses if managed jobs are active. Remount Drive before further persistence operations. |
| safe_stopA | Save all managed workspaces and stop the VM only after Drive confirms its flush. Unmanaged processes and files outside the workspace are not captured. Saving failures leave the VM running so the user can recover. Refuses while managed jobs are active. |
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 9 tools
Each tool has a distinct role in the lifecycle, and descriptions clarify boundaries. The main overlaps are restore_workspace versus prepare_workspace and save_workspaces versus safe_stop, but the descriptions make the differences clear enough for an agent to select correctly.
Most tools follow a verb_noun pattern such as restore_workspace, save_workspaces, start_runtime, and list_checkpoints. Minor deviations like runtime_status and safe_stop break the pattern slightly but remain readable and predictable.
Nine tools is well-scoped for the server's purpose of managing Colab runtimes, workspace persistence, and dataset planning. Each tool covers a meaningful lifecycle step without unnecessary bloat or redundancy.
The surface covers the core workflow: start/stop runtime, status, save/restore workspaces, list checkpoints, prepare/run scripts, and dataset validation. Gaps include no explicit delete/cleanup tool and no in-tool mount/unmount operation, but these are referenced as external commands and do not block the main persistence workflow.