Skip to main content
Glama

colab_notebook_add_cell

Insert a code or markdown cell into a Colab notebook at the end, or place it at a specific position or after a given cell.

Instructions

Insert a cell. Default is at the end; or give position (index) or after (cell id/index). cell_type: code or markdown.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
afterNo
sourceYes
positionNo
cell_typeNocode

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the default insertion point and the two placement mechanisms, but a mutation tool with no annotation coverage says nothing about permissions, whether the notebook must already exist, or persistence/save behavior.

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 short sentences with the primary action front-loaded and zero filler; the placement rules follow immediately. It is appropriately sized, though very terse relative to what the mutation semantics arguably warrant.

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?

An output schema exists, so return values need no explanation and that gap is forgiven. However, for a mutation tool with no annotations, the description omits preconditions and the meaning of path/source, leaving the agent with only partial guidance.

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?

Schema description coverage is 0%, so the description must compensate. It meaningfully explains position (index), after (cell id/index), and cell_type (code or markdown), covering three of five parameters, but leaves path and source entirely unexplained.

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 opens with a clear verb+resource ('Insert a cell') and the notebook context comes from the tool name, cleanly separating it from siblings like colab_notebook_edit_cell or colab_notebook_delete_cell. It does not explicitly name any sibling, so it earns a solid 4 rather than a 5.

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?

It tells the agent how insertion placement works (default at end, or via position/after) but never says when to choose this tool over alternatives such as creating a notebook or editing an existing cell. Usage is implied by the operation rather than stated.

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