Which integrations are available for this server?

Controls Google Colab notebooks through a headless WebSocket proxy, enabling creation, editing, execution, and inspection of notebook cells without browser automation.

How do I use colab-mcp?

1. Click on "Deploy 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., "@colab-mcp Run a machine learning pipeline in Colab" 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.

colab-mcp

by DaneshSelwal

Overview Schema Source Related Servers Discussions Admin

Python

Local

Headless Colab MCP Server

colab-mcp is a FastMCP server for controlling Google Colab notebooks through a secure, headless WebSocket architecture. Agents can create, edit, run, and inspect notebook cells without browser automation or UI scraping.

Features

Headless Operation — Run notebook operations through a secure WebSocket proxy
Zero Browser Management — No Chromium, browser profiles, or DOM scraping
ML-Ready Tooling — Workspace setup, dataset handling, and pipeline execution
Structured Results — Typed stdout, stderr, file paths, and error details
FastMCP Integration — Clean MCP server interface for tool composition

Related MCP server: JupyterMCP

Architecture

The server uses two cooperating layers:

ColabSessionProxy

Starts a localhost WebSocket server
Generates a one-time connection URL with mcpProxyToken and mcpProxyPort
Waits for an authenticated Colab tab to attach

NotebookController

Exposes the stable MCP tool surface
Discovers proxy capabilities from the connected Colab frontend
Maps server-owned tools to proxy-backed cell operations
Falls back to direct runtime execution only when needed

Requirements

Requirement	Version
Python	3.13+
uv	Latest
Google Colab	Active browser session

Installation

uv sync
uv run colab-mcp

Configuration

Add this to your MCP configuration:

{
  "mcpServers": {
    "colab-mcp-local": {
      "command": "uv",
      "args": ["run", "colab-mcp"],
      "cwd": "${workspaceFolder}",
      "timeout": 30000
    }
  }
}

API Reference

Core Notebook Tools

Tool	Description
`connect_colab(notebook_url?)`	Initialize connection and retrieve proxy URL
`list_colab_cells()`	List all cells in the notebook
`read_colab_cell(cell_id)`	Read a specific cell
`write_colab_cell(code, cell_id?, mode?)`	Write code to a cell
`run_colab_cell(cell_id?, wait?, timeout_seconds?)`	Execute a cell
`run_colab_code(code, mode?, wait?, timeout_seconds?)`	Write and execute code in one step
`get_colab_output(cell_id?)`	Retrieve execution output
`save_colab_notebook()`	Save the notebook
`run_runtime_code(code)`	Execute code directly in the runtime

ML Workflow Tools

Tool	Description
`setup_ml_workspace(packages)`	Install packages and create standard data directories
`fetch_remote_dataset(download_url, extract_to)`	Download and extract datasets
`execute_ml_pipeline(code_block)`	Execute Python blocks with structured results

Usage

Start the MCP server.
Call connect_colab to get a connect_url, proxy_token, and proxy_port.
Paste the connect_url into an active Colab tab.
Wait for the proxy connection to establish.
Run notebook operations through the MCP tools.

Example

uv run colab-mcp
connect_colab()
setup_ml_workspace(["pandas", "scikit-learn"])
fetch_remote_dataset(url, "/content/data")
execute_ml_pipeline(training_code)
get_colab_output()

Development & Verification

PYTHONPATH=src python scripts/smoke_test.py
PYTHONPATH=src py -m pytest
cat RELEASE_CHECKLIST.md

Test coverage

Proxy capability discovery
Native Colab argument mapping
Cell ID extraction
ML tool routing through proxy
Execution result normalization

License

This project is licensed under the Apache License 2.0.

Acknowledgments

This headless WebSocket proxy architecture was inspired by the open-source work provided by the Google Colab team.

Available Tools

13 tools

connect_colabD

ParametersJSON Schema

Name	Required	Description	Default
`notebook_url`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`backend`	No
`message`	No
`connected`	Yes
`proxy_port`	No
`connect_url`	No
`proxy_token`	No
`capabilities`	No
`notebook_url`	No
`proxy_connected`	No
`browser_attached`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

execute_ml_pipelineD

ParametersJSON Schema

Name	Required	Description	Default
`code_block`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`stderr`	No
`stdout`	No
`traceback`	No
`error_name`	No
`error_value`	No
`raw_execution`	No
`generated_file_paths`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

fetch_remote_datasetD

ParametersJSON Schema

Name	Required	Description	Default
`extract_to`	Yes
`download_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`stderr`	No
`stdout`	No
`cell_id`	No
`traceback`	No
`error_name`	No
`error_value`	No
`text_result`	No
`display_items`	No
`execution_count`	No
`raw_backend_payload`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_colab_outputD

ParametersJSON Schema

Name	Required	Description	Default
`cell_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`stderr`	No
`stdout`	No
`cell_id`	No
`traceback`	No
`error_name`	No
`error_value`	No
`text_result`	No
`display_items`	No
`execution_count`	No
`raw_backend_payload`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_colab_cellsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Checks whether a Google Colab proxy session is already connected. Returns a boolean representing whether the headless proxy connection is available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It clearly discloses that the tool returns a boolean indicating headless proxy connection availability, and it implies a read-only check with no side effects. However, it does not explicitly mention safety or lack of side effects, though this is implied for a status check.

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 the purpose, and every word adds value. There is no redundancy or filler.

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?

The tool is simple (no params) and has an output schema (though not shown). The description adequately covers the tool's purpose and return value. It lacks explicit usage guidance, but that is covered in the usage dimension. Overall, it is complete for a low-complexity 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?

The tool has zero parameters, making the input schema trivially complete. The description adds no parameter-specific detail, but none is needed. The baseline for 0 params is 4, and the description appropriately focuses on the return value rather than parameters.

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 performs a check on a Google Colab proxy session and explicitly mentions it returns a boolean about connection availability. This is specific and distinct from sibling tools like connect_colab (which establishes a connection) and read_colab_cell (which reads content).

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?

The description implies the tool is used to verify whether a proxy connection already exists, but it does not explicitly state when to use it versus alternatives like connect_colab. It provides context but lacks clear 'use this before connecting' or 'use to check status' guidance.

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

read_colab_cellD

ParametersJSON Schema

Name	Required	Description	Default
`cell_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`code`	No
`cell_id`	Yes
`outputs`	No
`preview`	No
`cell_type`	No
`execution_count`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

run_colab_cellD

ParametersJSON Schema

Name	Required	Description	Default
`wait`	No
`cell_id`	No
`timeout_seconds`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`stderr`	No
`stdout`	No
`cell_id`	No
`traceback`	No
`error_name`	No
`error_value`	No
`text_result`	No
`display_items`	No
`execution_count`	No
`raw_backend_payload`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

run_colab_codeD

ParametersJSON Schema

Name	Required	Default
`code`	Yes
`mode`	No	append
`wait`	No
`timeout_seconds`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`stderr`	No
`stdout`	No
`cell_id`	No
`traceback`	No
`error_name`	No
`error_value`	No
`text_result`	No
`display_items`	No
`execution_count`	No
`raw_backend_payload`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

run_runtime_codeD

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`stderr`	No
`stdout`	No
`cell_id`	No
`traceback`	No
`error_name`	No
`error_value`	No
`text_result`	No
`display_items`	No
`execution_count`	No
`raw_backend_payload`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

save_colab_notebookD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`success`	Yes
`notebook_url`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

setup_ml_workspaceD

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`stderr`	No
`stdout`	No
`cell_id`	No
`traceback`	No
`error_name`	No
`error_value`	No
`text_result`	No
`display_items`	No
`execution_count`	No
`raw_backend_payload`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

write_colab_cellD

ParametersJSON Schema

Name	Required	Default
`code`	Yes
`mode`	No	append
`cell_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`code`	No
`cell_id`	Yes
`outputs`	No
`preview`	No
`cell_type`	No
`execution_count`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

13 tool updatesv0.1.0Aug 9, 2026
- First observedconnect_colab
- First observedexecute_ml_pipeline
- First observedfetch_remote_dataset
- First observedget_colab_output
- First observedlist_colab_cells
- First observedopen_colab_browser_connection
- First observedread_colab_cell
- First observedrun_colab_cell
- First observedrun_colab_code
- First observedrun_runtime_code
- First observedsave_colab_notebook
- First observedsetup_ml_workspace
- First observedwrite_colab_cell

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

D1.7/5.0

Scored 2026-08-09 19:30 across 13 tools

Disambiguation2/5

Several tools appear to serve similar purposes: run_colab_cell, run_colab_code, run_runtime_code, and execute_ml_pipeline all seem to execute code, while connect_colab and open_colab_browser_connection overlap in establishing/checking a connection. Without descriptions, it's hard for an agent to pick the right tool.

Naming Consistency3/5

Most tools follow a verb_noun snake_case pattern, but there's inconsistency: some include 'colab' (e.g., list_colab_cells) while others do not (e.g., setup_ml_workspace, fetch_remote_dataset). Also, the verbs vary widely, making the naming feel less systematic than a strict verb_noun convention.

Tool Count4/5

13 tools is within a reasonable range for a Colab-focused server. However, the presence of four overlapping execution tools inflates the count and suggests some consolidation could improve the set without losing functionality.

Completeness3/5

The tool surface covers core cell operations (read, write, run, output) and notebook saving, but lacks obvious lifecycle operations like deleting a cell or creating a notebook. The ML-related tools (setup workspace, fetch dataset, pipeline) add breadth but also introduce unclear boundaries and gaps, such as no explicit tool for managing datasets beyond fetching.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
28
browserbasehq-mcp-browserbaseOAuth
ai.smithery
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
Browser Automation Web Scraping Agent Orchestration
23,407
Living DocsOAuth
io.github.s2bomb
Create and improve live, shared interactive documents with your agent.
Workplace & Productivity Note Taking
1
TabfleetOAuth
com.tabfleet
Launch, inspect, control, and share isolated cloud browsers for your agents.
Agent Orchestration Browser Automation
1

Related MCP Servers

Colab MCP
Code Execution AI & Machine Learning Developer Tools
aerovfx
A
license
B
quality
D
maintenance
An MCP server that bridges local AI agents to Google Colab notebooks, enabling execution of Python code and interaction with notebook states directly from the agent.
Updated 5 months ago (2026-04-23 07:34 UTC)
1
Apache 2.0
JupyterMCP
Code Execution Developer Tools AI & Machine Learning
Try3D
A
license
A
quality
C
maintenance
Enables AI agents to create, read, edit, and execute Jupyter notebook cells, manage kernels, and connect to remote Jupyter servers.
Updated 5 months ago (2026-04-17 11:28 UTC)
21
MIT
notebook-agent-mcp
Code Execution Developer Tools
KJH-Sun
F
license
Not graded
quality
D
maintenance
Enables AI agents to execute Jupyter notebook cells with persistent kernel state, output persistence, and structured JSON control surface.
Updated 6 months ago (2026-03-18 10:08 UTC)
2
-
colab-autopilot
Agent Orchestration Code Execution AI & Machine Learning
Emile-Andre
A
license
Not graded
quality
D
maintenance
Enables AI agents to autonomously manage Google Colab GPU sessions, submit and monitor training jobs, and debug/fix issues via an encrypted tunnel without requiring a browser tab.
Updated 5 months ago (2026-04-07 17:51 UTC)
MIT