Create a new runtime session to execute code in Colab or Jupyter. Attach to an existing kernel via a connection file, or launch a local kernel by omitting it.
Open a new runtime session (a Colab/Jupyter kernel connection). Omit connection_file to launch a local kernel.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | default | |
| connection_file | No | Path to a Jupyter kernel connection file to attach to. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says it opens a new runtime session and mentions the connection_file behavior. It does not disclose side effects, whether the session persists, how to stop it, or resource implications. The description is largely a restatement of the tool's name plus a parameter hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and followed by the key parameter behavior. There is no filler or redundant text, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description should cover what happens when the session is created, what is returned, and any lifecycle considerations. It only covers the act of opening a session and the local-kernel option, leaving the agent to guess about return values and session management.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: connection_file has a schema description, while label does not. The description adds value for connection_file by explaining that omitting it launches a local kernel, which goes beyond the schema. However, it does not explain the purpose of label, leaving that parameter's semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action—opening a new runtime session—and clarifies that a runtime session is a Colab/Jupyter kernel connection. It differentiates from sibling tools like colab_create_notebook and colab_restart_runtime by emphasizing 'new' and the kernel-connection nature. The clause about omitting connection_file further refines the tool's distinct behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a usage hint: 'Omit connection_file to launch a local kernel,' which implies when to use the attach vs. local-kernel path. However, it does not explicitly state when to prefer this tool over alternatives such as restart_runtime or get_runtime, nor does it provide exclusions. Usage guidance is present but mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.