Which integrations are available for this server?

Allocates Google Colab GPU/TPU runtimes and executes Python code on them, supporting accelerators like T4, L4, A100, H100, G4, and TPUs V5E1, V6E1, with background execution and automatic runtime release. Enables file upload, download, and automated file transfer between Google Drive and Colab runtime, supporting Drive fetch before code execution and Drive save after completion.

How do I use mcp-colab-gpu?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-colab-gpu Train a PyTorch model on T4" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-colab-gpu

by mio-github

Overview Schema Related Servers Score Discussions

Python

Remote

mcp-colab-gpu

Extended MCP server for Google Colab GPU/TPU runtimes

Based on mcp-server-colab-exec by Paritosh Dwivedi (MIT License). Thank you for the original idea and implementation! / 素晴らしいアイデアと実装に感謝します！

MCP server that allocates Google Colab GPU/TPU runtimes and executes Python code on them. Lets any MCP-compatible AI assistant -- Claude Code, Claude Desktop, Gemini CLI, Cline, and others -- run GPU/TPU-accelerated code (CUDA, PyTorch, TensorFlow, JAX) without local GPU hardware.

What's different from the original

Feature	mcp-server-colab-exec	mcp-colab-gpu
GPU support	T4, L4	T4, L4, A100, H100, G4
TPU support	--	V5E1, V6E1
High-memory runtime	--	Supported
Google Drive integration	--	Upload / Download / Fetch / Save
Background execution	--	Non-blocking with poll
Runtime release	Manual	Automatic on completion
Input validation	--	Accelerator + timeout validation
Path traversal protection	--	.py-only + resolved symlinks
Zip slip protection	--	Member path validation
Token file permissions	Default	0600 (owner-only)
Token refresh error logging	Silent	Logged with re-auth fallback

Related MCP server: mcp-server-colab-exec

Supported accelerators

Accelerator	VRAM / Memory	Tier
`T4`	16 GB	Free
`L4`	22 GB	Colab Pro
`A100`	40 GB	Colab Pro / Pro+
`H100`	80 GB	Colab Pro+
`G4`	95 GB	Colab Pro+
`V5E1`	TPU v5e-1	Colab Pro+
`V6E1`	TPU v6e-1	Colab Pro+

Prerequisites

Python 3.10+
A Google account with access to Google Colab
On first run, a browser window opens for OAuth2 consent. The token is cached at ~/.config/colab-exec/token.json for subsequent runs.

Installation

With uvx (recommended)

uvx mcp-colab-gpu

With pip

pip install mcp-colab-gpu

Claude Code configuration

Add to your project's .mcp.json or ~/.claude/.mcp.json:

{
  "mcpServers": {
    "colab-gpu": {
      "command": "uvx",
      "args": ["mcp-colab-gpu"]
    }
  }
}

Or via the CLI:

# Project-local (this project only)
claude mcp add colab-gpu -- uvx mcp-colab-gpu

# User-global (available in all projects)
claude mcp add --scope user colab-gpu -- uvx mcp-colab-gpu

Claude Desktop configuration

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "colab-gpu": {
      "command": "uvx",
      "args": ["mcp-colab-gpu"]
    }
  }
}

Tools

`colab_execute`

Execute inline Python code on a Colab GPU/TPU runtime.

Parameter	Type	Default	Description
`code`	string	--	Python code to execute (required)
`accelerator`	string	`"T4"`	GPU/TPU type: `T4`, `L4`, `A100`, `H100`, `G4`, `V5E1`, `V6E1`
`high_memory`	bool	`false`	Enable high-memory runtime (more RAM)
`timeout`	int	`300`	Max execution time in seconds (10--3600)
`background`	bool	`false`	Run in background (non-blocking). Returns a `job_id` to poll via `colab_poll`. Incompatible with `drive_fetch`/`drive_save`.
`drive_fetch`	string	`""`	JSON mapping Drive paths to Colab paths. Files are downloaded from Google Drive before your code runs. Example: `'{"colab_data/train.csv": "/content/train.csv"}'`
`drive_save`	string	`""`	JSON mapping Colab paths to Drive paths. Files are uploaded to Google Drive after your code finishes (with a freshly obtained token). Example: `'{"/content/model.pt": "results/model.pt"}'`

Returns JSON with per-cell output, errors, and stderr.

`colab_execute_file`

Execute a local .py file on a Colab GPU/TPU runtime.

Parameter	Type	Default	Description
`file_path`	string	--	Path to a local `.py` file (required)
`accelerator`	string	`"T4"`	GPU/TPU type: `T4`, `L4`, `A100`, `H100`, `G4`, `V5E1`, `V6E1`
`high_memory`	bool	`false`	Enable high-memory runtime (more RAM)
`timeout`	int	`300`	Max execution time in seconds (10--3600)

Returns JSON with per-cell output, errors, and stderr.

`colab_execute_notebook`

Execute code and collect all generated artifacts (images, CSVs, models, etc.).

Parameter	Type	Default	Description
`code`	string	--	Python code to execute (required)
`output_dir`	string	--	Local directory for downloaded artifacts (required)
`accelerator`	string	`"T4"`	GPU/TPU type: `T4`, `L4`, `A100`, `H100`, `G4`, `V5E1`, `V6E1`
`high_memory`	bool	`false`	Enable high-memory runtime (more RAM)
`timeout`	int	`300`	Max execution time in seconds (10--3600)

Artifacts are downloaded as a zip and extracted into output_dir.

`colab_poll`

Poll a background job for its current status and results.

Parameter	Type	Default	Description
`job_id`	string	--	The job identifier returned by `colab_execute(..., background=true)` (required)

Returns JSON with job_id, status (starting, running, completed, failed), accelerator, timestamps, and result (when completed) or error (when failed).

`colab_jobs`

List all tracked background jobs.

No parameters. Returns a JSON array of job summaries including job_id, status, accelerator, and timestamps.

`colab_drive_upload`

Upload a local file to Google Drive.

Parameter	Type	Default	Description
`local_path`	string	--	Path to the local file to upload (required)
`drive_folder`	string	`"colab_data"`	Target folder path on Google Drive (relative to MyDrive). Nested paths like `data/train` are supported. Folders are created automatically.

Returns JSON with drive_file_id, filename, drive_folder, and colab_path.

`colab_drive_download`

Download a file from Google Drive to a local path.

Parameter	Type	Default	Description
`drive_path`	string	--	File path on Google Drive relative to MyDrive (e.g. `results/model.pt`) (required)
`local_path`	string	--	Local destination path (required)

Returns JSON with local_path, drive_file_id, and size_bytes.

`colab_version`

Return the mcp-colab-gpu server version. No parameters.

Examples

Just ask in natural language / プロンプトで話しかけるだけ

Once this MCP server is configured, you can use GPU/TPU from any MCP-compatible AI assistant just by asking in natural language. No API calls, no boilerplate -- just describe what you want.

このMCPサーバーを設定すれば、Claude CodeなどのMCP対応AIアシスタントに日本語で話しかけるだけでGPU/TPUが使えます。APIコールもボイラープレートも不要です。

Claude Code / Claude Desktop / Gemini CLI / Cline:

"A100でResNet-50をCIFAR-10で10エポック学習させて、精度を教えて"

"Train a ResNet-50 on CIFAR-10 for 10 epochs using A100 and report the accuracy"

"H100でphi-2を動かして、量子コンピューティングについて説明させて"

"Run phi-2 on H100 and ask it to explain quantum computing"

"手元のtrain.csvをDriveにアップして、GPUで前処理してから結果をダウンロードして"

"Upload my local train.csv to Drive, preprocess it on GPU, and download the results"

"バックグラウンドでStable Diffusionの画像を100枚生成して、終わったら教えて"

"Generate 100 images with Stable Diffusion in the background and let me know when it's done"

The AI assistant automatically selects the right tool, writes the code, executes it on Colab, and returns the results -- all from a single prompt.

AIアシスタントが適切なツールを自動選択し、コードを書き、Colabで実行し、結果を返します。すべてひとつのプロンプトから。

Check GPU availability

colab_execute(code="import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))")

Matrix multiplication benchmark on A100

colab_execute(
    code="""
import torch
import time

device = torch.device('cuda')
print(f"GPU: {torch.cuda.get_device_name(0)}")
print(f"Memory: {torch.cuda.get_device_properties(0).total_mem / 1e9:.1f} GB")

# Benchmark: large matrix multiplication
a = torch.randn(8192, 8192, device=device)
b = torch.randn(8192, 8192, device=device)

torch.cuda.synchronize()
start = time.time()
c = torch.mm(a, b)
torch.cuda.synchronize()
elapsed = time.time() - start

tflops = 2 * 8192**3 / elapsed / 1e12
print(f"8192x8192 matmul: {elapsed:.3f}s ({tflops:.1f} TFLOPS)")
""",
    accelerator="A100",
    high_memory=True,
)

Background execution with polling

# 1. Start a long-running job in the background
colab_execute(
    code="""
import torch
model = torch.hub.load('pytorch/vision', 'resnet152', pretrained=True)
model = model.cuda().eval()
dummy = torch.randn(64, 3, 224, 224, device='cuda')
with torch.no_grad():
    for i in range(100):
        output = model(dummy)
print(f"Completed 100 inference batches")
""",
    accelerator="A100",
    background=True,
)
# Returns: {"job_id": "abc123def456", "status": "starting"}

# 2. Poll for results
colab_poll(job_id="abc123def456")
# Returns: {"job_id": "...", "status": "running", ...}

# 3. When complete
colab_poll(job_id="abc123def456")
# Returns: {"job_id": "...", "status": "completed", "result": {...}}

# 4. List all jobs
colab_jobs()
# Returns: {"jobs": [...], "count": 1}

Google Drive: upload data, process on GPU, download results

# 1. Upload training data to Drive
colab_drive_upload(local_path="./data/train.csv", drive_folder="colab_data")

# 2. Execute on Colab with Drive fetch + save
colab_execute(
    code="""
import pandas as pd
import torch

df = pd.read_csv('/content/train.csv')
print(f"Loaded {len(df)} rows")

# ... GPU training ...

torch.save(model.state_dict(), '/content/model.pt')
print("Model saved")
""",
    accelerator="A100",
    drive_fetch='{"colab_data/train.csv": "/content/train.csv"}',
    drive_save='{"/content/model.pt": "results/model.pt"}',
    timeout=600,
)

# 3. Download results from Drive
colab_drive_download(drive_path="results/model.pt", local_path="./model.pt")

LLM inference on H100

colab_execute(
    code="""
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_name = "microsoft/phi-2"
tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
    model_name, torch_dtype=torch.float16, device_map="auto", trust_remote_code=True
)

prompt = "Explain quantum computing in one paragraph:"
inputs = tokenizer(prompt, return_tensors="pt").to("cuda")
outputs = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))
""",
    accelerator="H100",
    timeout=600,
)

Train and download model weights

colab_execute_notebook(
    code="""
import torch
import torch.nn as nn

model = nn.Sequential(nn.Linear(784, 256), nn.ReLU(), nn.Linear(256, 10))
model = model.cuda()
# ... training code ...
torch.save(model.state_dict(), '/tmp/model.pt')
print("Model saved!")
""",
    output_dir="./outputs",
    accelerator="T4",
)

Authentication

Colab runtime

On first use, the server opens a browser window for Google OAuth2 consent. The access token and refresh token are cached at ~/.config/colab-exec/token.json. Subsequent runs use the cached token and refresh it automatically.

The OAuth2 client credentials are the same ones used by the official Google Colab VS Code extension (google.colab@0.3.0). They are intentionally public.

Google Drive (v0.3.0+)

Drive tools (colab_drive_upload, colab_drive_download, drive_fetch, drive_save) use a separate OAuth2 token with the drive.file scope. On first Drive operation, a second browser window opens for consent. The token is cached at ~/.config/colab-exec/drive_token.json.

This separate token means:

Users who only use colab_execute are never asked for Drive permissions.
Drive access is limited to the drive.file scope (only files created by this app).

To use your own OAuth client instead of the built-in one, set the environment variable MCP_DRIVE_CLIENT_JSON or place a drive_client.json file at ~/.config/colab-exec/drive_client.json.

Design: zero CU waste

Colab compute units (CU) are consumed while a runtime is allocated. This server releases runtimes immediately after code execution finishes -- not when the client disconnects or the session times out.

Sync execution: allocate -> execute -> release (all in one call)
Background execution: allocate -> execute -> release on completion (not on poll)
Drive fetch/save: all three steps (fetch, execute, save) run on the same allocation, released once all steps finish

This means you only pay for actual computation time, never for idle runtimes.

Security improvements

This fork includes the following security hardening over the original:

Path validation in colab_execute_file: Only .py files are accepted. Paths are resolved through pathlib.Path.resolve() to prevent symlink-based traversal attacks.
Zip slip protection in colab_execute_notebook: Every member in a downloaded artifact zip is validated to ensure its resolved path stays within the target output_dir, preventing directory traversal via crafted zip entries.
Path traversal protection in Drive operations: Local paths in colab_drive_upload and colab_drive_download reject .. segments to prevent directory traversal.
Drive query injection prevention: Folder and file names are escaped before being used in Drive API query strings.
Token file permissions: The OAuth token cache files (token.json, drive_token.json) are created with 0o600 permissions (owner read/write only) using os.open instead of plain open.
Input validation: The accelerator parameter is validated against the known set of supported accelerators, and timeout is bounded to 10--3600 seconds, before any network calls are made.
Token refresh error logging: When automatic token refresh fails, the error is logged to stderr with a warning message before falling back to re-authentication, instead of silently discarding the error.

Troubleshooting

"GPU quota exceeded" -- Colab has usage limits. Wait and retry, or use a different Google account.

"Timed out creating kernel session" -- The runtime took too long to start. Retry -- Colab sometimes has delays during peak usage.

"Authentication failed" -- Delete ~/.config/colab-exec/token.json and re-authenticate.

"Drive authentication failed" -- Delete ~/.config/colab-exec/drive_token.json and re-authenticate.

"A background job is already running" -- Only one background job can run at a time (Colab single-GPU constraint). Wait for the current job to finish or poll its status with colab_poll.

OAuth browser window doesn't open -- Ensure you're running in an environment with a browser. For headless servers, authenticate on a machine with a browser first and copy the token file.

Acknowledgments / 謝辞

English

Special thanks to Paritosh Dwivedi (@pdwi2020) for creating mcp-server-colab-exec. Your original idea of bridging MCP-compatible AI assistants with Google Colab GPU runtimes was brilliant and made this extended fork possible. We hope this project helps more developers leverage cloud GPUs from their local AI workflows.

日本語

Paritosh Dwivedi (@pdwi2020) 氏の mcp-server-colab-exec に心より感謝いたします。MCP対応のAIアシスタントとGoogle ColabのGPUランタイムを橋渡しするという素晴らしいアイデアと実装のおかげで、この拡張フォークを実現することができました。このプロジェクトが、より多くの開発者がローカルのAIワークフローからクラウドGPUを活用する助けになることを願っています。

About the maintainer

Masaya Hirano -- CEO of Mio System Co., Ltd., CRO of TrustedAI Corporation

License

MIT

Available Tools

10 tools

colab_cancelA

Destructive

Cancel an active background job.

Marks the job as cancelled and attempts to cancel the underlying asyncio task. Use colab_jobs to find active job IDs.

After cancellation:

Verify with colab_poll(job_id) that the status is 'cancelled'.
The Colab runtime is released automatically.
You can then start a new background job with colab_execute.

Common issues:

Cannot cancel a job that is already completed, failed, or cancelled.
Use colab_jobs first if you don't have the job_id.

Args: job_id: The job identifier returned by colab_execute.

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, but the description adds value by explaining the underlying async task cancellation, automatic runtime release, and verification step. No contradiction.

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?

Well-structured with sections for main action, post-cancellation steps, common issues, and args. Front-loaded with purpose. A bit lengthy but every sentence adds value.

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?

Given an output schema exists (not shown), return values are not needed. The description covers purpose, usage, behavioral effects, common issues, and sibling references thoroughly for a cancellation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (job_id) with 0% schema description coverage. The description explains it as 'The job identifier returned by colab_execute,' which is clear and sufficient given the single required param.

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?

The description clearly states 'Cancel an active background job' and explains the action (marks as cancelled, cancels async task). It distinguishes from siblings by referencing colab_execute, colab_jobs, and colab_poll for different lifecycle stages.

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?

Explicitly states when to use (cancel active job), when not to (cannot cancel already completed/failed/cancelled), and recommends colab_jobs first if job_id is unknown. Provides post-cancellation steps (verify with colab_poll, then start new job with colab_execute).

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

colab_drive_downloadA

Download a file from Google Drive to a local path.

Use this to retrieve results saved to Drive by colab_execute with the drive_save parameter, or any file stored on Google Drive.

After download:

The file is saved at the specified local_path.
Process or inspect the file locally as needed.

Common issues:

File not found: verify the drive_path matches the Drive folder structure (relative to MyDrive root).
First use requires Google Drive OAuth authorization.

Args: drive_path: File path on Google Drive relative to MyDrive (e.g. 'results/model.pt' or 'colab_data/output.csv'). local_path: Local destination path where the file will be saved.

ParametersJSON Schema

Name	Required	Description	Default
`drive_path`	Yes
`local_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already indicate non-read-only and non-destructive. The description adds details about the download process, local file creation, and first-use OAuth, providing behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with purpose, followed by usage guidelines, then common issues in bullet points. Every sentence adds value with no wasted words.

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?

Given the tool's simplicity, an output schema exists, so return values don't need explanation. The description covers purpose, usage, parameters, and troubleshooting thoroughly, making it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by documenting both parameters: drive_path relative to MyDrive and local_path as destination. This adds crucial meaning beyond the schema.

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?

The description clearly states the tool downloads a file from Google Drive to a local path, specifying the exact resource and action. It distinguishes from siblings like colab_drive_upload and colab_execute by focusing on retrieval.

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

Usage Guidelines4/5

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

The description explicitly says to use this for retrieving results from colab_execute or any Drive file, and lists common issues like file not found and OAuth. It doesn't explicitly mention when not to use or alternatives, but the context is clear.

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

colab_drive_uploadA

Upload a local file to Google Drive.

Use this to stage input data before running colab_execute with the drive_fetch parameter. The file is uploaded to the specified folder under MyDrive.

After upload:

Pass the drive path in colab_execute's drive_fetch parameter to make the file available on the Colab runtime.
Example: colab_execute(code="...", drive_fetch='{"colab_data/train.csv": "/content/train.csv"}')

Common issues:

First use requires Google Drive OAuth authorization (browser popup).
Nested folders (e.g. 'data/train') are created automatically.

Args: local_path: Path to the local file to upload. drive_folder: Target folder path on Google Drive (relative to MyDrive). Nested paths like 'data/train' are supported. Folders are created automatically if they don't exist. Default: "colab_data".

ParametersJSON Schema

Name	Required	Description	Default
`local_path`	Yes
`drive_folder`	No		colab_data

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

Discloses OAuth authorization requirement and automatic folder creation. Annotations already indicate non-read-only and non-destructive nature. Missing details about overwrite behavior and file size limits.

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?

Well-structured with separate sections for usage, post-upload steps, common issues, and Args. Concise but not overly terse; each sentence adds useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers prerequisites (OAuth), integration with colab_execute, and common issues. Output schema exists but description doesn't mention return value; still fairly complete for the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has no parameter descriptions (0% coverage). Description explains both parameters thoroughly: local_path is path to local file, drive_folder includes default value, nested folder support, and auto-creation. Adds significant value beyond the schema.

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?

Clear verb 'Upload', specific resource 'local file to Google Drive', and distinguishes from sibling tools by mentioning its role in staging data for colab_execute.

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

Usage Guidelines4/5

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

Explicitly states when to use: before colab_execute with drive_fetch parameter. Provides usage example and mentions OAuth prerequisite, but lacks explicit when-not-to-use guidance.

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

colab_executeA

Execute Python code on a Google Colab GPU/TPU runtime.

Primary tool for running GPU/TPU-accelerated Python code (ML training, inference, CUDA operations). Allocates hardware, runs the code, and returns structured JSON with per-cell output, errors, and stderr.

After execution:

If background=True, poll with colab_poll(job_id) for results.
If OOM error occurs, reduce batch_size or upgrade to A100/H100.
If import error, add pip install <pkg> before your main code.
To persist outputs to Google Drive, use the drive_save parameter.
To pre-load data from Drive, use the drive_fetch parameter.

Common issues:

QUOTA_EXCEEDED: Colab rate limit hit. Wait a few minutes or switch to a different accelerator type.
CUDA_ERROR: Driver mismatch or GPU init failure. Retry, or try T4.
Only ONE background job can run at a time (Colab limitation).

Args: code: Python code to execute on the Colab runtime. accelerator: Hardware accelerator type. Default: "T4". GPU types: "T4" - NVIDIA Tesla T4 (16 GB, free-tier) "L4" - NVIDIA L4 (24 GB, Colab Pro) "A100" - NVIDIA A100 (40 GB, Colab Pro/Pro+) "H100" - NVIDIA H100 (80 GB, Colab Pro+) "G4" - NVIDIA G4 (Colab Pro+) TPU types: "V5E1" - TPU v5e-1 (Colab Pro+) "V6E1" - TPU v6e-1 (Colab Pro+) high_memory: Enable high-memory runtime (more RAM). Default: False. timeout: Max execution time in seconds (10-3600). Default: 300. background: Run in background (non-blocking). Default: False. When True, returns immediately with a job_id that can be polled via colab_poll. Incompatible with drive_fetch/drive_save. drive_fetch: JSON mapping Drive paths to Colab paths. Files are downloaded from Google Drive BEFORE your code runs. Example: '{"colab_data/train.csv": "/content/train.csv"}' Requires prior colab_drive_upload to place files on Drive. drive_save: JSON mapping Colab paths to Drive paths. Files are uploaded to Google Drive AFTER your code finishes, using a freshly obtained token (safe for long-running tasks). Example: '{"/content/model.pt": "results/model.pt"}'

ParametersJSON Schema

Name	Required	Default
`code`	Yes
`timeout`	No
`background`	No
`drive_save`	No
`accelerator`	No	T4
`drive_fetch`	No
`high_memory`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries full burden. It extensively discloses behaviors: hardware allocation, structured JSON return, background job limitations (only one at a time), error handling for OOM, import errors, rate limits, and CUDA errors. It also explains side effects of drive_fetch/drive_save and the need for fresh tokens.

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?

The description is well-structured with a clear first sentence, followed by execution context, common issues, and a parameter list. It is front-loaded with key information. However, it is somewhat lengthy; a slightly more concise breakdown could improve readability, but the level of detail is justified by the tool's complexity.

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?

Given the tool's complexity (7 parameters, background jobs, accelerator types, drive integration), the description covers all essential aspects: purpose, usage flow, error scenarios, parameter details, and return behavior. It also references sibling tools (colab_poll) and notes limitations, making it a complete guide for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates fully with detailed parameter explanations: accelerator types with GPU/TPU lists, examples for drive_fetch/drive_save, defaults, and constraints (e.g., background incompatible with drive operations). This goes well beyond what the bare schema provides.

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?

The description clearly states 'Execute Python code on a Google Colab GPU/TPU runtime,' providing a specific verb and resource. It distinguishes itself from siblings by positioning as the 'primary tool' for running GPU/TPU-accelerated code and mentions background execution with polling, which differentiates it from other execute tools like colab_execute_file or colab_execute_notebook.

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

Usage Guidelines4/5

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

The description gives clear context on when to use the tool (primary for GPU/TPU code) and includes after-execution steps (polling, error handling) and common issues. However, it lacks explicit guidance on when NOT to use this tool versus specific siblings, such as using colab_execute_file for file-based execution or colab_execute_notebook for notebooks.

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

colab_execute_fileA

Execute a local Python file on a Google Colab GPU/TPU runtime.

Reads the file contents and sends them for execution on a Colab runtime. Use this instead of colab_execute when you already have a .py script file ready to run.

After execution:

Check exit_code and cell outputs in the response.
If you need to collect output files (models, images), use colab_execute_notebook instead.

Common issues:

Only .py files are accepted (security restriction).
File must exist at the given path on the local machine.

Args: file_path: Path to a local .py file to execute on Colab. accelerator: Hardware accelerator type. Default: "T4". GPU types: "T4" - NVIDIA Tesla T4 (16 GB, free-tier) "L4" - NVIDIA L4 (24 GB, Colab Pro) "A100" - NVIDIA A100 (40 GB, Colab Pro/Pro+) "H100" - NVIDIA H100 (80 GB, Colab Pro+) "G4" - NVIDIA G4 (Colab Pro+) TPU types: "V5E1" - TPU v5e-1 (Colab Pro+) "V6E1" - TPU v6e-1 (Colab Pro+) high_memory: Enable high-memory runtime (more RAM). Default: False. timeout: Max execution time in seconds (10-3600). Default: 300.

ParametersJSON Schema

Name	Required	Default
`timeout`	No
`file_path`	Yes
`accelerator`	No	T4
`high_memory`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

Discloses security restriction (only .py files), file existence requirement, and response structure (exit_code, cell outputs). Could add more on runtime side effects, but annotations are minimal so description adds significant value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections, front-loaded purpose, and no redundant information. Every sentence adds value.

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?

Covers purpose, usage, parameters, execution flow, and post-execution steps. Output schema exists, so return details are not needed. Complete for a 4-param tool with sibling context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage, but description provides full parameter details including accelerator options with availability tiers, high_memory, timeout, and required file_path. Compensates completely.

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?

Clearly states the tool executes a local Python file on Colab with specific hardware. Differentiates from sibling tools colab_execute and colab_execute_notebook.

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?

Provides explicit when-to-use (for .py files) and when-to-use alternatives (colab_execute_notebook for output files). Includes common issues and post-execution instructions.

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

colab_execute_notebookA

Execute Python code on Colab GPU/TPU and collect generated artifacts.

Runs the code, then scans the runtime for output files (images, CSVs, models, etc.), zips them, and downloads to a local directory. Use this when your code produces files you need to retrieve locally.

After execution:

Check artifact_files in the response for collected output filenames.
Files are extracted to the specified output_dir.
For files larger than 50 MB, use colab_execute with drive_save instead.

Common issues:

No artifacts collected: ensure your code writes files to /tmp, /content, or the current working directory.
Each artifact file must be under 50 MB (base64 transfer limit).

Args: code: Python code to execute on the Colab runtime. output_dir: Local directory to save the artifacts zip and extracted files. accelerator: Hardware accelerator type. Default: "T4". GPU types: "T4" - NVIDIA Tesla T4 (16 GB, free-tier) "L4" - NVIDIA L4 (24 GB, Colab Pro) "A100" - NVIDIA A100 (40 GB, Colab Pro/Pro+) "H100" - NVIDIA H100 (80 GB, Colab Pro+) "G4" - NVIDIA G4 (Colab Pro+) TPU types: "V5E1" - TPU v5e-1 (Colab Pro+) "V6E1" - TPU v6e-1 (Colab Pro+) high_memory: Enable high-memory runtime (more RAM). Default: False. timeout: Max execution time in seconds (10-3600). Default: 300.

ParametersJSON Schema

Name	Required	Default
`code`	Yes
`timeout`	No
`output_dir`	Yes
`accelerator`	No	T4
`high_memory`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

The description details what the tool does after execution: scans runtime for artifacts, zips them, and downloads to local directory. It discloses file size limits (50 MB per artifact) and expected artifact locations. Annotations provide no contradictory info, and description adds significant behavioral context beyond them.

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?

The description is well-structured with clear sections (after execution, common issues, args) and is front-loaded with purpose. It is slightly lengthy but every sentence serves a purpose. Could be marginally tightened.

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?

Given the tool's complexity (5 parameters, artifact handling, output schema), the description covers all necessary aspects: what the tool does, how to use it, parameter details, expected outputs, common issues, and even limitations. The existence of an output schema is acknowledged by mentioning response fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description extensively documents each parameter: code, output_dir, accelerator (with full list of GPU/TPU types and their VRAM/plan), high_memory, and timeout. This adds crucial meaning beyond the bare schema titles.

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?

The description clearly states the tool executes Python code on Colab GPU/TPU and collects generated artifacts. It distinguishes itself from siblings by focusing on artifact retrieval, and includes a usage directive: 'Use this when your code produces files you need to retrieve locally.'

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?

The description explicitly tells when to use this tool (when producing files) and when not (for files >50MB, use colab_execute with drive_save). It also provides post-execution steps and common issues, offering clear guidance on alternatives.

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

colab_jobsA

Read-only

List all tracked background jobs.

Returns a JSON array of job summaries including job_id, status, accelerator type, and timestamps. Use this to find job IDs for colab_poll or colab_cancel.

After listing:

Use colab_poll(job_id) on any job to get detailed results.
Use colab_cancel(job_id) to stop an active job.
Completed/failed/cancelled jobs are auto-cleaned after 5 minutes.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark readOnlyHint true and destructiveHint false, so the tool is safe. The description adds value by detailing the return format (JSON array with job_id, status, accelerator type, timestamps) and cleanup policy (5 minutes auto-clean). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with 4 sentences, front-loaded with the main action, and each sentence adds essential information without waste.

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?

Given no parameters, an output schema (implied), and sibling tools, the description fully covers what the tool does, what it returns, how to use its results, and cleanup behavior. It is complete for agent selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description correctly omits parameter information as none exist.

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?

The description clearly states the tool lists all tracked background jobs, which is a specific verb+resource. It distinguishes from siblings like colab_poll and colab_cancel by noting this tool provides job IDs for them.

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?

The description explicitly tells when to use this tool (to find job IDs) and provides clear next steps: use colab_poll for details, colab_cancel to stop, and notes auto-cleanup. This guides the agent on context and alternatives.

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

colab_pollA

Read-only

Poll a background job for its current status and results.

Use this after launching a background execution with colab_execute(..., background=True) to check progress and retrieve results when complete.

Interpreting the response:

status='starting' or 'running': job is in progress, poll again later.
status='completed': result field contains the execution output.
status='failed': error field describes what went wrong.
status='cancelled': job was stopped via colab_cancel.

Common issues:

Unknown job_id: use colab_jobs to list all tracked jobs.
Jobs are cleaned up automatically after 5 minutes.

Args: job_id: The job identifier returned by colab_execute.

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing the response statuses (starting/running/completed/failed/cancelled), cleanup after 5 minutes, and common issues, providing rich behavioral context beyond the annotations.

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?

The description is well-structured with sections for usage, response interpretation, common issues, and args. It is front-loaded with the purpose and avoids unnecessary words, though it is slightly lengthy.

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?

Given the existence of an output schema, the description adequately covers all necessary context: usage, response interpretation, common issues, and parameter semantics. It is complete for a polling tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description compensates by explaining job_id as 'The job identifier returned by colab_execute', adding meaning to the only parameter.

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?

The description clearly states 'Poll a background job for its current status and results' and distinguishes itself by explicitly directing usage after colab_execute(..., background=True), differentiating from sibling tools like colab_jobs and colab_cancel.

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?

It explicitly says when to use ('after launching a background execution with colab_execute(..., background=True)') and provides context for when not to use or alternatives (e.g., 'use colab_jobs to list all tracked jobs' for unknown job_id).

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

colab_statusA

Read-only

Return current server status including accelerator info and job state.

Use this before executing code to check which accelerators are available and whether a background job is already running (only one background job is allowed at a time).

After checking status:

Choose an accelerator from supported_accelerators for colab_execute.
If active_job is present, wait for it or cancel with colab_cancel before starting a new background job.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the one-background-job limit and the need to check before executing, which is valuable beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: first states purpose, second gives usage context, third provides post-check actions. No wasted words; structure is front-loaded and efficient.

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?

Covers purpose, when to use, and what to do with the results. The output schema exists to describe return values, so the description is complete for this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. The description does not need to add parameter information.

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?

The description clearly states the tool returns current server status with accelerator info and job state. It distinguishes itself from sibling tools like colab_execute and colab_cancel by being a read-only status check.

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?

Explicitly advises to use before executing code and provides follow-up actions: choose accelerator for colab_execute, wait or cancel if a job is running. This is clear guidance.

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

colab_versionA

Read-only

Return the mcp-colab-gpu server version.

Use this to verify server compatibility or for debugging.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations (readOnlyHint, destructiveHint) already cover safety. Description adds use context (debugging) without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with verb, no wasted words. Perfectly concise.

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?

Given no parameters, existing output schema, and annotations, description fully explains purpose and usage. Complete for a simple version tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; schema coverage is 100%. Baseline for 0 parameters is 4, and description does not need to add parameter details.

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?

Description clearly states 'Return the mcp-colab-gpu server version' with a specific verb and resource. It distinguishes from sibling tools like colab_execute by being unique in purpose.

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

Usage Guidelines4/5

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

Explicitly says to use for 'verifying server compatibility or debugging', which provides clear guidance. No alternatives needed given simplicity.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.3.1Jul 30, 2026
- First observedcolab_cancel
- First observedcolab_drive_download
- First observedcolab_drive_upload
- First observedcolab_execute
- First observedcolab_execute_file
- First observedcolab_execute_notebook
- First observedcolab_jobs
- First observedcolab_poll
- First observedcolab_status
- First observedcolab_version

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: execution variants (colab_execute, colab_execute_file, colab_execute_notebook) differ in input and output handling, job management tools are separate, and Drive utilities are distinct. No overlap that would cause misselection.

Naming Consistency5/5

All tools follow the consistent 'colab_' prefix with snake_case verb_noun pattern (e.g., colab_execute, colab_poll, colab_drive_upload). No mixing of conventions.

Tool Count5/5

10 tools is well-scoped for a GPU execution server: three execution variants, job lifecycle management, Drive integration, and status/version check. Each tool earns its place without being excessive or sparse.

Completeness4/5

Covers core workflows: code execution (with file and artifact options), job management, Drive upload/download, and status. Minor gaps like lack of a tool to list Drive files or manage folders, but overall sufficient for common tasks.

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Server4AgentOAuth
com.server4agent
Give any MCP-compatible AI assistant a builder for live, hosted web tools and workflows.
App Automation Developer Tools Browser Automation
2
ContextStream BOAuth
io.contextstream
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
Knowledge & Memory Developer Tools
30241
Writingmate MCPOAuth
ai.writingmate
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI & Machine Learning Image & Video Processing
1
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297

Related MCP Servers

colab-mcp
Shell Access File Systems Code Execution
404F0X
A
license
B
quality
D
maintenance
Local-first MCP server for controlling Google Colab as a development, shell, file, and training runtime, with tools for notebook editing, GPU acceleration, and file transfer.
Updated 4 months ago (2026-05-05 14:04 UTC)
59
7
Apache 2.0
mcp-server-colab-exec
Code Execution AI & Machine Learning
pdwi2020
A
license
A
quality
D
maintenance
MCP server that allocates Google Colab GPU runtimes (T4/L4) and executes Python code on them. Lets any MCP-compatible AI assistant run GPU-accelerated code without local GPU hardware.
Updated 6 months ago (2026-03-11 18:31 UTC)
3
8
MIT
mcp-server-kaggle-exec
Code Execution AI & Machine Learning
pdwi2020
A
license
Not graded
quality
D
maintenance
Enables running GPU-accelerated Python code on Kaggle from any MCP-compatible AI assistant without local GPU hardware.
Updated 7 months ago (2026-02-15 17:12 UTC)
MIT
claude-colab
Code Execution Shell Access Cloud Platforms
LakshmiSravyaVedantham
A
license
Not graded
quality
F
maintenance
Enables Claude Code to execute shell commands, Python code, and file transfers on a Google Colab T4 GPU via an MCP server, bridging the GPU gap for AI coding agents.
Updated 6 months ago (2026-03-21 00:18 UTC)
5
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mio-github/mcp-colab-gpu'

If you have feedback or need assistance with the MCP directory API, please join our Discord server