Which integrations are available for this server?

Uses Google Cloud OAuth credentials for authentication, enabling programmatic access to Colab's runtime API for GPU control. Provides tools for controlling Google Colab notebooks, including adding, editing, running, and deleting cells, as well as managing runtime and GPU assignments. Allows assignment of NVIDIA GPUs (T4, L4, A100) to Colab runtimes via the change_runtime tool.

colab-mcp (enhanced fork)

by SebastianGilPinzon

Overview Schema Related Servers Score Discussions

Python

Local

Colab MCP (Enhanced Fork)

License Python MCP Stars

An MCP server for controlling Google Colab from any AI coding agent. This fork fixes the bugs in the official repo that block real day-to-day use and restores features Google removed upstream.

Why This Fork?

Three concrete dolores that the official googlecolab/colab-mcp doesn't solve — and that this fork does:

Invisible tools (#54, #67, #69) — only open_colab_browser_connection appears in most MCP clients (Claude Code, Codex, Kiro IDE). The notebook tools rely on notifications/tools/list_changed, which these clients ignore. Without get_cells in particular, the bridge is effectively write-only: an agent can add cells but can't read state back.
"Disconnected from the local Colab MCP server" (#84) — orphaned servers from prior Claude Code sessions hold ports that your browser tab still points at. Reconnecting from the tab silently fails.
No programmatic GPU control — Google removed the --enable-runtime feature entirely. You can't assign T4 / L4 / A100 without clicking in the browser.

This fork fixes all three. All 9 tools (1 connection + 7 notebook + 1 GPU control) appear immediately, stale servers are auto-detected and clean-uppable, and GPUs are assignable from a single tool call.

Demo coming soon: docs/demo.gif (TODO — short asciinema of change_runtime → add_code_cell → run_code_cell).

Related MCP server: mcp-colab-gpu

What's Different

Feature	Official	This Fork
Notebook tools visible at startup	No (needs browser + list_changed)	Yes (pre-registered, works with any client)
`change_runtime` tool (GPU control)	Removed	Working via OAuth
OAuth token caching	N/A	Yes (authorize once, cached forever)
Windows compatibility	Port 53919 blocked	Fixed (port 8085)
ColabClient initialization	N/A	Fixed (Prod() env argument)
Stale-server detection / cleanup	None — silent "Disconnected"	`--list-running` + `--kill-stale`, registry pruning on startup

Available Tools

Tool	Requires Browser	Requires OAuth	Description
`change_runtime`		Yes	Assign GPU: T4, L4, A100, or NONE
`open_colab_browser_connection`	Yes		Connect to a Colab notebook in your browser
`add_code_cell`	Yes		Add a code cell to the notebook
`add_text_cell`	Yes		Add a markdown cell
`get_cells`	Yes		Read current notebook state (cells, IDs, contents, outputs)
`run_code_cell`	Yes		Execute a code cell by `cellId`
`update_cell`	Yes		Edit an existing cell by `cellId`
`delete_cell`	Yes		Delete a cell by `cellId`
`move_cell`	Yes		Move a cell to a new position by `cellId`

Note: execute_cell was renamed to run_code_cell in 2026-06-16 to match the browser-side handler name. Pass a cellId (from add_code_cell or get_cells) — the old cellIndex fallback was removed.

Quick Start (Without OAuth)

If you just want the notebook tools (no change_runtime):

1. Install uv

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

# Mac/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

Important: Do NOT use pip install uv — that version lacks required features.

2. Clone this repo

git clone https://github.com/SebastianGilPinzon/colab-mcp.git

3. Configure your MCP client

Add to your .mcp.json (Claude Code, Cursor, etc.):

{
  "mcpServers": {
    "colab-proxy-mcp": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/colab-mcp", "colab-mcp"],
      "timeout": 30000
    }
  }
}

4. Use it

Restart your editor / reload window
All 8 tools should appear immediately (open_colab_browser_connection + 7 notebook tools)
Call open_colab_browser_connection — a Colab notebook opens in your browser
Use add_code_cell, run_code_cell, get_cells, etc. to control the notebook

Full Setup (With OAuth + GPU Control)

This enables the change_runtime tool, which lets your agent assign GPUs without you touching the browser.

1. Create OAuth Credentials

You need a Google Cloud project with OAuth configured. This is a one-time setup (~5 minutes):

Create a GCP project (or use an existing one):

gcloud projects create colab-mcp-oauth --name="Colab MCP OAuth"

Configure OAuth consent screen:
- Go to OAuth consent screen
- Select "External" > Create
- App name: Colab MCP, add your email as support + developer contact
- Save through all steps
Add yourself as test user:
- On the consent screen page > "Test users" > Add your Google email
Create OAuth client ID:
- Go to Credentials
- Create Credentials > OAuth client ID > Desktop app
- Download the JSON file
- Save it somewhere safe (e.g., ~/.config/colab-oauth.json)

Note: OAuth Client IDs can only be created via the Cloud Console web UI. There is no CLI or API for this.

2. Configure MCP with OAuth

{
  "mcpServers": {
    "colab-proxy-mcp": {
      "command": "uv",
      "args": [
        "run", "--directory", "/path/to/colab-mcp",
        "colab-mcp",
        "--client-oauth-config", "/path/to/colab-oauth.json"
      ],
      "timeout": 30000
    }
  }
}

3. Authorize (first time only)

The first time the server starts, it opens your browser for Google OAuth consent. Sign in, click Allow, done. The token is cached at ~/.colab-mcp-auth-token.json and auto-refreshes — you won't be asked again.

4. Use it

Agent: change_runtime(accelerator="T4")
> Runtime changed to T4. Endpoint: gpu-t4-s-xxx

Agent: open_colab_browser_connection()
> Connected. Available notebook tools: add_code_cell, add_text_cell, get_cells, run_code_cell, update_cell, delete_cell, move_cell

Agent: add_code_cell(code="!nvidia-smi")
> {"cellId": "abc123", ...}

Agent: run_code_cell(cellId="abc123")
> Tesla T4, 15GB memory...

Agent: get_cells()
> [{"cellId": "abc123", "code": "!nvidia-smi", "outputs": [...]}]

CLI Reference

Once installed (via uv run or uvx git+https://github.com/SebastianGilPinzon/colab-mcp), the colab-mcp command supports these flags:

Flag	Description
(none)	Start the MCP server (default — reads/writes JSON-RPC on stdin/stdout)
`-l DIR`, `--log DIR`	Write logs to `DIR`. Defaults to a temp dir under `%TEMP%` / `$TMPDIR`
`-p`, `--enable-proxy`	Enable the runtime proxy that exposes browser-based notebook tools. On by default
`--client-oauth-config PATH`	Path to OAuth client-secrets JSON. Enables the `change_runtime` tool for programmatic GPU assignment
`--list-running`	Print every currently-running `colab-mcp` server (pid, port, host, start time) and exit. Useful when "Disconnected from the local Colab MCP server" appears
`--kill-stale`	Terminate every running `colab-mcp` server, clear its registry entry, and exit. Use this from a regular shell (NOT from inside Claude Code) before starting a fresh session

The server maintains a tiny registry at %LOCALAPPDATA%\colab-mcp\registry.json (Windows) or ~/.colab-mcp/registry.json (macOS/Linux). Each running instance writes a {pid, port, host, started_at} entry on startup and removes it on clean shutdown. Stale entries from crashed processes are pruned automatically the next time colab-mcp starts.

Troubleshooting

Tools don't appear after setup

Make sure you're using this fork, not the official repo
Only define colab-proxy-mcp in ONE .mcp.json file (not both global and project — dual definitions spawn two server instances and one dies silently)
Restart your editor after changing .mcp.json

`change_runtime` returns "Runtime API not initialized"

Check that --client-oauth-config is in your .mcp.json args
Check that the OAuth JSON file exists at the specified path

Look at the server logs for the specific error:

# Find the latest log
ls -t $TMPDIR/colab-mcp-logs-*/colab-mcp.*.log | head -1 | xargs cat

A healthy log shows: INFO:Colab API client ready
If you see WARNING:Failed to initialize Colab API client, check the error message

Windows: Port blocked error (WinError 10013)

Already fixed in this fork (changed to port 8085). If you still hit it, edit src/colab_mcp/auth.py and change OAUTH_SERVER_PORT to any open port.

OAuth says "Access denied"

Add your Google email as a test user in Cloud Console > OAuth consent screen > Test users.

Browser opens but connection times out

Make sure you have a Colab notebook open in the browser tab that opened. Click "Connect" if prompted.

Chrome reused an old Colab tab pointing at a dead port

Chrome dedupes tabs by URL canonical (ignoring the #fragment), so when an old Colab tab is still open with a fragment pointing at a previous server's port, calling open_colab_browser_connection again may silently focus the old tab instead of opening a fresh one. The old tab shows "Disconnected from the local Colab MCP server" and the new server times out.

This fork mitigates that by appending the current port as a query param (?p=<port>) to the Colab URL, so each server instance produces a unique URL that Chrome can't dedupe. If you still hit it after upgrading:

Close every colab.research.google.com tab in your browser.
Retry open_colab_browser_connection — it will open a fresh tab pointed at the live server.

Chrome silently blocks every connection attempt after one previous "Block"

If Chrome shows "Disconnected from the local Colab MCP server" on every attempt — including immediately after the page loads, with no permission prompt — and the server logs only stream ends after 0 bytes (TCP opens then closes without any HTTP request), the most likely cause is that you previously clicked "Block" on the Local Network Access prompt for colab.research.google.com. Chrome remembers that choice per site and never asks again — every WebSocket attempt is silently cancelled before the handshake. Edge / Firefox / other Chromium profiles are unaffected.

Fix (Chrome):

Open chrome://settings/content/siteDetails?site=https%3A%2F%2Fcolab.research.google.com
Find "Access other devices on the network" / "Acceder a otros dispositivos en la red" / Insecure content
Change from Block to Ask
Reload the Colab tab and accept the prompt when it appears.

Quickest reset (clears all Colab site permissions):

Open https://colab.research.google.com
Click the lock icon next to the URL
Click "Reset permissions" / "Restablecer permisos"
Reload and try again.

This was reproduced and root-caused with a manual E2E test (scripts/manual_browser_test.py): Edge connected on first attempt, Chrome timed out indefinitely until the per-site permission was reset.

Chrome asks for "Permission to access other services and apps on this device" (or Colab says "Disconnected")

When the Colab tab loads, Chrome shows a permission prompt:

colab.research.google.com wants — Permission to access other services and apps on this device

Click Allow. If you block it, the WebSocket connection from the Colab tab to your local colab-mcp server is blocked, the tab shows "Disconnected from the local Colab MCP server", and open_colab_browser_connection will time out.

This prompt is Chrome's Local Network Access policy: a public site (https://colab.research.google.com) is asking to talk to a resource on your local network (ws://localhost:<port> where colab-mcp is listening). Chrome blocks this by default and asks the user. The "other service" in the prompt is your own colab-mcp server running on your machine — not external access. The connection is scoped to a one-time token in the URL fragment (#mcpProxyToken=...), so even on the same machine other processes can't piggy-back on it.

Chrome remembers the choice per-site, so you only need to allow it once for colab.research.google.com.

"Disconnected from the local Colab MCP server" — IPv4/IPv6 dual-stack bind (root cause)

If you saw this message on the official googlecolab/colab-mcp and assumed it was an orphaned-server issue, the actual root cause is different — and is fixed in this fork.

With host="localhost" + port=0, the websockets library binds two sockets on different ephemeral ports (one for IPv6 ::1 and one for IPv4 127.0.0.1), then reports only one of them as the "server port". The Colab tab opens ws://localhost:<reported-port>, Chrome resolves localhost to either address family, and connects to a port with no listener in 50% of cases. The TCP connection drops with stream ends after 0 bytes server-side, the Colab tab shows "Disconnected from the local Colab MCP server" instantly, and the user waits 60s for a generic timeout.

This fork forces IPv4-only (host="127.0.0.1") so there is exactly one socket on exactly one port, and asserts this invariant at startup (raising RuntimeError if a future change re-introduces the dual-bind). See websocket_server.py and the tests test_single_socket_single_port / test_default_host_is_ipv4.

Orphaned colab-mcp processes (separate issue)

If a Colab tab in your browser shows "Disconnected from the local Colab MCP server" and re-clicking Connect doesn't help, the cause is almost always one or more orphaned colab-mcp processes from previous Claude Code sessions. Each instance picks a random ephemeral port, but your Colab tab only remembers the port from the URL fragment used when it first opened — when that server dies (or you spawn a new Claude Code session with a new server on a different port), the tab keeps trying to reach a dead address.

This fork ships with built-in diagnostics. Run any of these from a regular shell (not from inside Claude Code, which is itself running an MCP instance):

# Show every colab-mcp server currently registered as running
uv run --directory /path/to/colab-mcp colab-mcp --list-running

# Terminate orphaned colab-mcp servers, then exit
uv run --directory /path/to/colab-mcp colab-mcp --kill-stale

The server writes a small registry file at %LOCALAPPDATA%\colab-mcp\registry.json (Windows) or ~/.colab-mcp/registry.json (macOS/Linux) listing pid + port for each running instance. On every startup it prunes dead entries automatically, and on clean shutdown it removes its own. If open_colab_browser_connection times out from inside Claude Code, the new error message also includes the ports + pids of any peer servers so you can identify which one your browser tab is actually pointed at.

After cleaning up, re-run open_colab_browser_connection — it will open a fresh Colab tab pointed at the current (only) server's port + token.

Fixes upstream issue #84.

Compatibility

Tested with:

Claude Code (VS Code extension + CLI)
Should work with any MCP client that supports the standard tool protocol (Cursor, Windsurf, Codex, etc.)

Supported platforms:

Windows 10/11
macOS
Linux

Changes from Upstream

This fork is based on googlecolab/colab-mcp with these changes:

f70c00d Register notebook tools directly on the FastMCP server at startup (fixes invisible tools)
cae498b Add change_runtime tool with OAuth for programmatic GPU assignment
440e3bc Fix ColabClient initialization (missing Prod() env arg) + change OAuth port to 8085 for Windows
e66ee69 Match real Colab API signatures (language param, cellId, run_code_cell)
stale-server detection Process registry + --list-running / --kill-stale flags + clearer timeout diagnostics — fixes upstream #84 "Disconnected from the local Colab MCP server"
full 7-tool notebook surface — pre-register get_cells, delete_cell, move_cell (previously missing) and rename execute_cell → run_code_cell to match the browser-side handler. Closes upstream #69.

Google does not accept external contributions to the official repo, so these fixes live here.

Verified fixes (accepted in upstream discussions)

#67 → answered — invisible-tools fix (this fork's pre-registration approach was accepted by the upstream community as the working solution).
#69 — follow-up on get_cells and the remaining missing stubs — addressed in this fork on 2026-06-16.
#84 — "Disconnected from the local Colab MCP server" — addressed via the stale-server registry + --kill-stale CLI.

License

Apache 2.0 (same as upstream)

⭐ If this fork saved you time, a star helps others find it.

Available Tools

9 tools

add_code_cellC

Add a new code cell to the Colab notebook. Requires an active browser connection via open_colab_browser_connection.

ParametersJSON Schema

Name	Required	Default
`code`	No
`cellIndex`	No
`language`	No	python

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states the action and prerequisite, but does not disclose that the tool modifies the notebook state, nor does it mention any potential side effects or safety concerns.

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

Conciseness2/5

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

The description is only one sentence, which is concise but under-specified. It omits critical details that would be valuable for correct invocation, such as parameter roles or positional insertion behavior.

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

Completeness2/5

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

Given the tool has 3 parameters with no descriptions and no annotation coverage, the description is far from complete. The existence of an output schema does not compensate for missing semantic guidance on inputs and usage context.

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

Parameters1/5

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

Schema description coverage is 0% for the 3 parameters, and the description adds no information about what 'code', 'cellIndex', or 'language' mean, how they are used, or expected formats. The description provides no parameter-level guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action of adding a code cell, distinguishing it from adding a text cell by specifying 'code cell.' However, it does not mention the ability to insert at a specific index, which is implied by the cellIndex parameter.

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

Usage Guidelines2/5

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

The description mentions a necessary prerequisite (active browser connection via open_colab_browser_connection) but provides no guidance on when to use this tool versus siblings like add_text_cell, change_runtime, or delete_cell.

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

add_text_cellB

Add a new text/markdown cell to the Colab notebook. Requires an active browser connection via open_colab_browser_connection.

ParametersJSON Schema

Name	Required	Description	Default
`content`	No
`cellIndex`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, description carries full burden but only adds a prerequisite. Fails to disclose if addition is immediate, idempotent, or any constraints on content.

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?

Two concise sentences, front-loaded with the main action. Could benefit from including parameter details without becoming verbose.

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

Completeness2/5

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

Given a simple tool with an output schema, omitting parameter descriptions and behavioral details makes it incomplete for reliable invocation.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no explanation for 'content' or 'cellIndex' parameters, leaving their purpose and constraints unclear.

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 'Add a new text/markdown cell', specifying verb and resource. Distinguishes from sibling 'add_code_cell' which adds code instead of text.

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 requires an active browser connection via 'open_colab_browser_connection', providing essential usage context. However, no exclusions or comparisons to alternatives like 'update_cell'.

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

change_runtimeA

Change the Colab runtime to use a specific GPU accelerator. Valid values: NONE, T4, L4, A100. Requires OAuth setup (first time opens browser for consent).

ParametersJSON Schema

Name	Required	Description	Default
`accelerator`	No		T4

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?

With no annotations provided, the description carries full burden. It discloses the behavioral trait of changing the accelerator and the OAuth requirement, which is adequate for a simple mutation tool.

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 two sentences, front-loaded with purpose and valid values, then the prerequisite. Every sentence earns its place with no 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 the low complexity (single parameter, no required params, output schema exists), the description is complete. It covers purpose, allowed values, and a key prerequisite.

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%, so the description must compensate. It adds meaning to the 'accelerator' parameter by listing valid values, fully covering what the schema lacks.

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 changes the Colab runtime to use a specific GPU accelerator, listing valid values (NONE, T4, L4, A100). It distinguishes itself from sibling tools, none of which are related to runtime or accelerator settings.

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 lists valid accelerator values and mentions the OAuth setup requirement for first use. While it does not compare to alternatives, the context is clear and provides necessary usage guidance.

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

delete_cellA

Delete a cell from the Colab notebook by cellId. Requires an active browser connection via open_colab_browser_connection.

ParametersJSON Schema

Name	Required	Description	Default
`cellId`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

States destructive action (delete) and prerequisite. No annotations exist, so description carries burden. Could mention error handling or irreversibility, but sufficient for a simple deletion.

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, no fluff. Action stated first, prerequisite second. Efficient and well-structured.

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

Completeness3/5

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

Has output schema so return values not needed. But lacks details on success/error behavior, resource impact, or edge cases (e.g., invalid cellId). Adequate but not comprehensive.

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

Parameters2/5

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

Schema coverage 0%; description only restates parameter name 'by cellId' without explaining its format, origin, or that it's likely required despite optional schema. Adds minimal value.

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 ('Delete'), resource ('cell from Colab notebook'), and parameter ('by cellId'). Distinguishes from sibling tools like add_cell or move_cell.

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?

Explicit prerequisite: 'Requires an active browser connection via open_colab_browser_connection.' Provides clear context for when to use, though no explicit mention of when not to or alternatives.

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

get_cellsA

Read the current notebook state: list of cells with their IDs, contents, and outputs. Essential for iterative work (write -> run -> read -> adjust). Requires an active browser connection via open_colab_browser_connection.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, description covers that it is a read operation and lists returned data. It mentions the prerequisite connection but could add details like no side effects or limitations. Adequate given simplicity.

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 concise sentences, front-loaded with purpose, no waste.

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?

Given zero parameters and existence of output schema, description covers return type and prerequisite. Lacks explanation of 'current notebook state' but sufficient for agent.

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; baseline score of 4 applies. Description does not need to add parameter info.

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 verb (Read) and resource (current notebook state: cells) and specifies what is returned (IDs, contents, outputs). It distinguishes from sibling write tools.

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?

Provides explicit usage context ('Essential for iterative work') and a prerequisite ('Requires an active browser connection via open_colab_browser_connection'). Could mention when not to use or alternative read tools if any, but still clear.

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

move_cellA

Move a cell to a new position in the Colab notebook by cellId and target index. Requires an active browser connection via open_colab_browser_connection.

ParametersJSON Schema

Name	Required	Description	Default
`cellId`	No
`cellIndex`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully convey behavioral traits. It only mentions the prerequisite and the move action, but fails to disclose potential side effects (e.g., whether it is destructive, reversible, or what happens if the cellId is invalid). The description is insufficient for safe invocation.

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 a single concise sentence that front-loads the core action and prerequisite. It avoids unnecessary words, though it could benefit from slightly more structure to separate purpose from requirement.

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

Completeness3/5

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

Given the tool's moderate complexity (a move operation with a prerequisite), the description covers the essential purpose and a key dependency. However, it lacks details on error handling, behavior with invalid inputs, and coordination with sibling tools like update_cell. An output schema exists but is not shown; the description does not reference it.

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

Parameters2/5

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

With 0% schema description coverage, the description should compensate by explaining parameter meaning. It mentions 'cellId' and 'target index' but does not clarify the index's base (0-based or 1-based), valid ranges, or relationships between parameters. This leaves ambiguity for correct usage.

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 action ('Move a cell'), the resource ('Colab notebook'), and the key parameters ('by cellId and target index'). It effectively distinguishes from sibling tools like add_code_cell or delete_cell by focusing on repositioning.

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 states a critical prerequisite: 'Requires an active browser connection via open_colab_browser_connection.' This guides the agent on necessary prior steps. However, it does not specify when not to use this tool or mention alternatives among siblings.

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

open_colab_browser_connectionA

Opens a connection to a Google Colab browser session and unlocks notebook editing tools. Returns whether the connection attempt succeeded.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only mentions opening connection and return value. Lacks details on authentication, idempotency, side effects, or failure behavior.

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, no verbose language. Front-loaded purpose and return value. Every sentence adds value.

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?

Given it's a simple connection tool with output schema, description adequately covers purpose and outcome. Could mention prerequisites or state implications of failure, but acceptable.

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; baseline score of 4 applies. Description adds no param info, but none needed.

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 verb 'opens a connection', resource 'Google Colab browser session', and outcome 'unlocks notebook editing tools'. Distinguishes from sibling tools which are about cell manipulation and runtime.

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

Usage Guidelines3/5

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

Implied use as a prerequisite for editing tools, but no explicit 'when to use' or alternatives provided. Context suggests it's a setup step, but not definitive.

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

run_code_cellA

Execute a code cell in the Colab notebook by cellId (from add_code_cell or get_cells). Requires an active browser connection via open_colab_browser_connection.

ParametersJSON Schema

Name	Required	Description	Default
`cellId`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the basic action and prerequisite, but does not explain what happens on execution (e.g., output handling, error behavior, side effects, or rate limits). This is insufficient for a tool that executes arbitrary code.

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 extremely concise: two short sentences, no redundant information, and front-loads the action. Every word serves a purpose.

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

Completeness2/5

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

Given the tool's complexity (executing code, with a prerequisite and output schema), the description is minimal. It lacks details on return values, error handling, and what 'execute' entails. The existence of an output schema is not leveraged to explain the response. This leaves the agent underinformed for safe and effective use.

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

Parameters3/5

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

The description adds meaning to the 'cellId' parameter by specifying it comes from 'add_code_cell or get_cells', which is helpful given the 0% schema description coverage. However, it does not explain format, constraints, or the fact that the schema marks it as not required (with default empty string), potentially causing confusion. More detail would be beneficial.

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 action ('Execute a code cell') and identifies the resource ('Colab notebook') and required parameter ('cellId'). It distinguishes from sibling tools by focusing on execution rather than addition, deletion, or modification.

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 specifies a prerequisite ('Requires an active browser connection via open_colab_browser_connection') and indicates the source of cellId ('from add_code_cell or get_cells'), giving context on when to use this tool. However, it does not provide explicit when-not-to-use guidance or compare to alternatives.

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

update_cellB

Update the contents of an existing cell in the Colab notebook. Requires an active browser connection via open_colab_browser_connection.

ParametersJSON Schema

Name	Required	Description	Default
`cellId`	No
`content`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It indicates mutation (update) but does not disclose permissions, reversibility, or whether content replaces or appends. More detail on behavioral traits is needed.

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: one for purpose, one for prerequisite. No wasted words. Front-loaded with the core action.

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

Completeness3/5

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

With output schema present, description need not explain return values. However, parameter details are missing, and for a simple update tool with 2 params, more context on content format or cell identification would improve completeness.

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

Parameters1/5

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

Schema coverage is 0%, meaning no parameter descriptions in the schema. The description does not explain cellId or content, their format, or expected values. It adds no 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 verb 'Update' and the resource 'contents of an existing cell in the Colab notebook'. This distinguishes it from sibling tools like add_code_cell, delete_cell, etc.

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?

It explicitly states a prerequisite: 'Requires an active browser connection via open_colab_browser_connection'. This gives clear context for when to use, though it does not exclude alternatives or mention when not to use.

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.

9 tool updatesv0.1.0Jun 19, 2026
- First observedadd_code_cell
- First observedadd_text_cell
- First observedchange_runtime
- First observeddelete_cell
- First observedget_cells
- First observedmove_cell
- First observedopen_colab_browser_connection
- First observedrun_code_cell
- First observedupdate_cell

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clear and distinct purpose, targeting specific actions like adding, deleting, moving, or running cells, with no overlapping functionality. The consistent requirement for an active browser connection via open_colab_browser_connection further clarifies dependencies.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., add_code_cell, get_cells, run_code_cell), making it easy for an agent to infer functionality from the name.

Tool Count5/5

With 9 tools, the server is well-scoped for its purpose of managing Google Colab notebooks. It covers essential operations without being overwhelming or too minimal.

Completeness4/5

The tool set covers core notebook interactions: connection, cell CRUD, execution, and runtime changes. Minor gaps exist, such as missing functions to clear output or restart the kernel, but the surface is sufficient for most workflows.

Maintenance

ActivityStale

ResponsivenessNo issues

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

climbpast
io.github.archievi
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Marketing Search Data Platforms
1
Tap
io.github.LeonTing1010
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Browser Automation Web Scraping
217
ToolforestOAuth
io.toolforest
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
Workplace & Productivity Health & Wellness Finance
2
dylog
io.github.imjakezimmer32
Notes, files, GitHub, and Drive through one MCP connection.
Note Taking Cloud Storage Version Control
1

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-colab-gpu
Code Execution AI & Machine Learning
mio-github
A
license
A
quality
C
maintenance
Enables MCP-compatible AI assistants to run Python code on Google Colab GPU/TPU runtimes, supporting accelerators like T4, A100, H100, with background execution and Google Drive integration.
Updated 6 months ago (2026-03-21 06:55 UTC)
10
2
MIT
colab-mcpofficial
Code Execution Autonomous Agents
googlecolab
A
license
A
quality
D
maintenance
Bridges a local agent to a Colab session in the browser, enabling seamless interaction with Colab from local clients.
Updated 2 months ago (2026-06-23 21:04 UTC)
1
915
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

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/SebastianGilPinzon/colab-mcp'

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

Colab MCP (Enhanced Fork)

Why This Fork?

What's Different

Available Tools

Quick Start (Without OAuth)

1. Install uv

2. Clone this repo

3. Configure your MCP client

4. Use it

Full Setup (With OAuth + GPU Control)

1. Create OAuth Credentials

2. Configure MCP with OAuth

3. Authorize (first time only)

4. Use it

CLI Reference

Troubleshooting

Tools don't appear after setup

change_runtime returns "Runtime API not initialized"

Windows: Port blocked error (WinError 10013)

OAuth says "Access denied"

Browser opens but connection times out

Chrome reused an old Colab tab pointing at a dead port

Chrome silently blocks every connection attempt after one previous "Block"

Chrome asks for "Permission to access other services and apps on this device" (or Colab says "Disconnected")

"Disconnected from the local Colab MCP server" — IPv4/IPv6 dual-stack bind (root cause)

Orphaned colab-mcp processes (separate issue)

Compatibility

Changes from Upstream

Verified fixes (accepted in upstream discussions)

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

colab-mcpofficial

Latest Blog Posts

MCP directory API

`change_runtime` returns "Runtime API not initialized"