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 states the transfer direction (VM to local working directory) but omits session requirements, overwrite/exists behavior on the destination, failure modes, and any rate or size limits for a file-transfer mutation.

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?

A single front-loaded sentence with no filler. It is efficient, though arguably too sparse for a tool with a required remote/local path pair and an unlabeled session parameter.

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?

An output schema exists, so return-value explanation is not required. However, with no annotations, 0% parameter coverage, and no usage routing, the definition leaves key invocation details (session selection, overwrite behavior, destination semantics) unstated.

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 description coverage is 0% across three parameters. The description only loosely implies remote_path (the VM file) and local_path (local destination) and says nothing about the optional session parameter, so it does not compensate for the empty schema.

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?

States a specific verb (Download) and resource (one file from the VM into the working directory). The word 'one' implicitly distinguishes it from the colab_download_dir sibling, though it does not name that alternative explicitly.

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?

Usage is only implied: the singular 'one file' hints at when to prefer this over colab_download_dir, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer the routing from the sibling name alone.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses zip-slip protection (refuses archives escaping the target) and a size cap with the exact env var and default (COLAB_MCP_MAX_DOWNLOAD_MB, 1024). It omits session/auth requirements and what happens on partial transfer.

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?

Two sentences, front-loaded with the action and target, followed by the failure constraints. No filler; every clause adds usable information.

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?

An output schema exists so return values need no explanation, and the safety constraints are covered. The gaps are the undocumented session parameter and the absence of annotation-level detail on permissions, which a 3-param mutation-of-local-state tool could reasonably specify.

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 0%, so the description must compensate. It clarifies that local_dir is resolved inside the working directory and implies remote_dir is the source folder, but the session parameter is left completely unexplained in both schema and description.

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?

States a specific verb and resource ('Download a whole VM folder ... via one zip'), and the word 'whole'/'folder' implicitly separates it from the file-oriented colab_download and the inverse colab_upload_dir. It stops short of naming those siblings explicitly, so an agent must infer the boundary.

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?

Usage is implied by 'whole VM folder' versus the single-file download sibling, and the refusal conditions hint at when the call will fail. There is no explicit statement of when to prefer this tool over colab_download or colab_ls, nor of prerequisites.

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

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

With no annotations, the description carries the full burden and does disclose the prerequisite user action, the cancel escape hatch, and the recommended verification step. It does not cover auth requirements, failure modes, or what a pending-vs-completed state looks like, leaving minor gaps.

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?

Three short clauses, front-loaded with the step identity and the critical ordering condition. No filler sentences.

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?

An output schema exists, so return values need not be described. The description is nearly complete for a 2-param tool but omits any explanation of the required session parameter and lacks auth/failure context.

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 description coverage is 0%, so the description must compensate; it explains cancel=true semantics well. However, the required 'session' parameter is never described in the text, so half the parameters remain undocumented.

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?

States it is 'Step 2 of mounting Google Drive' and that it 'Completes the mount', giving a specific verb+resource. It implies the pairing with colab_drive_mount_start (step 1) and names colab_drive_status, so an agent can place it in the flow without opening the schema.

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?

Explicit timing ('call it AFTER the user says they clicked Allow'), an explicit follow-up ('verify with colab_drive_status'), and an explicit abandonment path ('cancel=true abandons a pending mount'). When-to-call and what-to-do-next are both spelled out.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it reveals that the link is suppressed by default because it contains the account e-mail, that the user must click Allow manually, and that mounting grants VM code access to the user's WHOLE Drive. These are non-obvious side effects and auth requirements an agent could not infer from the schema.

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?

Front-loaded with the step and core action, and every sentence adds substance (link behavior, user action, drive-wide warning, next step). It is dense and slightly packed, but no sentence is filler.

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?

An output schema exists, so return values need not be re-explained. For a two-step, security-sensitive mount flow the description covers preconditions, the user's required action, side effects, safety constraints, and the next call — everything needed to invoke it correctly.

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 description coverage is 0%, so the description must compensate. It explains show_link's effect ('the link itself is NOT returned ... unless ... show_link=true'), giving meaningful semantics for the non-obvious parameter, while 'session' is self-evident from the surrounding tool family.

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?

States a specific verb+resource+stage: 'Step 1 of mounting Google Drive on a session: opens Google's approval page.' It explicitly frames itself against the sibling colab_drive_mount_finish ('Then call ... finish'), so an agent can distinguish the two-step flow without opening either schema.

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?

Gives explicit when-to-use ('mount only when asked'), safety exclusions ('never ask for or handle passwords or codes'), post-use guidance ('stop the session afterwards'), and names the required follow-up sibling tool. Nothing about selection or sequencing is left to inference.

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

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

With no annotations, the description carries the full burden. It usefully discloses idempotent behavior ('Create (if missing)') and the Drive-mounted prerequisite, but says nothing about error behavior, permissions, or what the optional session parameter changes.

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?

Three sentences, front-loaded with the action and resulting path, zero wasted words. Format/path scaffolding is given up front where an agent needs it.

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?

The tool is simple, an output schema exists so return values need no explanation, and the description covers purpose, path, and prerequisite. The remaining gap is the undocumented 'session' parameter.

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 description coverage is 0% for two parameters. The description conveys what 'name' means by embedding it in the path template, but the optional 'session' parameter is never mentioned in either the description or the schema, leaving a real semantic gap.

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?

States a specific verb+resource ('Create (if missing) and return a project folder') and even gives the exact path template. It is clearly distinguishable from Drive-management siblings, though it doesn't explicitly name an alternative tool for the same task.

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?

Gives clear context ('Use it for big datasets, checkpoints and results that must survive the session') and names the prerequisite by pointing to colab_drive_status. It stops short of explicit when-not guidance, but the usage context is well defined.

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

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

No annotations are provided, so the description carries the burden; it discloses output scope (yes/no plus free space, never file listings) and notes the browser-approval requirement in the mount flow. It does not explicitly state the call is read-only/side-effect free, though 'reports' implies it.

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?

Three short sentences, front-loaded with the core question, then output scope, then the routing hint. No filler.

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?

An output schema exists so return values need not be explained, and the description still sketches them. The only gap is the undocumented optional 'session' parameter, which is minor for a zero-required-param status check.

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 description coverage is 0% for the single optional 'session' parameter, and the description never mentions it or explains how the target session is resolved (default null). The description adds no meaning beyond the schema here.

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?

States a specific question the tool answers ('Is Google Drive mounted on this session?') and explicitly scopes the output ('yes/no and free space only, never lists your files'), which separates it from listing tools like colab_ls and from colab_drive_mount_start.

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?

Explicitly routes the agent: 'If it is not mounted, use colab_drive_mount_start (the user approves in the browser).' Names the alternative and the condition that selects it, plus the user-approval prerequisite.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses idempotency and the reuse-versus-create condition, but omits details such as authentication requirements, provisioning time, failure modes, or what creating a session entails.

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?

Two tight sentences, front-loaded with the core action and an important safety property. No wasted words.

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?

An output schema exists, so return details need not be explained. However, with no annotations and no parameter descriptions in the schema, the description is incomplete for three of four parameters and lacks behavioral details around session creation.

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 description coverage is 0%, so the description must compensate for four undocumented parameters. It only implies the required 'session' parameter through 'named session' and says nothing about gpu, tpu, or high_mem.

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 states a specific verb and resource ('Make sure a named session exists') and explains the reuse-or-create mechanism. It is clear what the tool does, but it does not explicitly contrast itself with sibling tools such as colab_new or colab_sessions.

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 phrase 'Safe to call repeatedly' implies usage for idempotent session setup, but the description does not explicitly state when to choose this over colab_new or other alternatives. Usage is inferable but not fully guided.

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

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

With no annotations, the description carries the full behavioral burden and does meaningful work: kernel-state persistence across calls, secrets injected as env vars whose values are never returned, and the .ipynb side-effect of writing '<name>_output.ipynb'. It omits blocking/error behavior and whether execution can modify or destroy runtime state.

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?

Front-loads the core purpose and persistence trait, then walks parameters in a scannable line-per-parameter structure with no filler. Slightly dense but every line carries information.

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?

An output schema exists, so return-value explanation is rightly omitted, and the description covers execution modes, secrets, plotting, and timeouts. The undocumented `session` parameter and the timeout default discrepancy keep it from being fully complete for a 6-parameter tool.

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 0%, so the description must compensate, and it documents 5 of 6 parameters (code, file, secrets, plot_path, timeout) with semantics the bare schema lacks. The `session` parameter is never explained, and the stated timeout CLI default (30) conflicts with the schema default (120).

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?

States a specific verb and resource ("Run Python on the runtime") and highlights the key scope trait (variables persist between calls in the same kernel). It names the colab_notebook_* family as the alternative for cell-by-cell work, though it does not disambiguate from the similarly-named sibling colab_run.

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?

Gives an explicit mutual-exclusion rule ("Give `code` or `file`, not both") and routes notebook-per-cell users to colab_notebook_* tools. It stops short of stating when to prefer this over colab_run or colab_install, so the routing is clear but not exhaustive.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the install mechanism ('uses uv, falls back to pip'), which is real behavioral context, but says nothing about side effects (e.g. kernel restart requirement), persistence, 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.

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

Two tight sentences, front-loaded with the action and the tooling detail, then the input format constraint. Nothing is redundant or padded.

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?

An output schema exists, so return values need not be described. However, for a 2-param mutation-style tool with no annotations, the unexplained 'session' parameter and unstated side effects leave clear gaps an agent would need to know.

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 0%, so the description must compensate. It does clarify the 'packages' argument format ('Names/specifiers only, e.g. qiskit, pandas>=2.0'), which is valuable, but the 'session' parameter is left entirely unexplained.

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?

States a concrete verb and resource ('Install Python packages on the runtime'), which is unambiguous. It is the only install-type tool among the siblings, so no explicit differentiation is required, but it never names a sibling or scope boundary to signal that.

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?

Usage is only implied (install before running code); there is no explicit when-to-use, precondition, or alternative. It does not mention, for example, that a session must exist first or when to prefer this over running pip inside colab_exec.

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

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

With no annotations, the description carries the full burden, and it does disclose the termination mechanism (SIGTERM to the process group), which is genuinely useful for reasoning about graceful vs. forced shutdown. However, it omits idempotency, error behavior for unknown/finished jobs, and whether the call blocks until exit.

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?

A single front-loaded sentence with the operation and its mechanism; no filler or redundancy.

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?

An output schema exists so return values need no explanation, and the mechanism detail helps. Still missing are the failure/edge-case contract (nonexistent or already-finished job), idempotency, and the meaning of the session parameter for a mutation tool with zero annotation coverage.

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 description coverage is 0% and the description does not mention either parameter. The optional 'session' argument is entirely unexplained, and there is no hint about job_id format or where to source it (colab_job_start/colab_job_list).

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?

States a specific verb (terminate) and a precisely scoped resource (a running background job), which distinguishes it from the session-scoped colab_stop and from the read-only colab_job_status/colab_job_logs siblings.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as checking colab_job_status first or using colab_job_list to obtain a job_id. The agent must infer the workflow entirely.

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

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 only states scope ('started on this VM') and does not disclose that the operation is read-only, non-destructive, or free of side effects, nor whether it requires session context or paginates results.

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?

A single front-loaded sentence with zero filler, appropriately sized for a list operation. It communicates the core action and scope without unnecessary verbosity.

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?

Although an output schema exists to cover return values and no annotations need reconciling, the description still leaves the session parameter unexplained and gives no routing guidance among the four sibling job tools. This is incomplete for an agent deciding how to invoke the tool and where it fits in the job-management workflow.

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 description coverage is 0% and the single optional 'session' parameter is undocumented in both the schema and the description. The description says 'all' jobs and never explains what the session parameter filters or means, so it does not compensate for the coverage gap.

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?

States a clear verb (List) and resource (background jobs) scoped to 'this VM', which distinguishes it from write-oriented siblings like colab_job_start, colab_job_cancel, and colab_job_logs. It does not explicitly name a sibling alternative or clarify how it relates to colab_job_status, so it stops short of a 5.

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 no indication of when to use this tool versus colab_job_status, colab_job_logs, or colab_job_cancel. It also does not mention that listing jobs is useful for discovering job IDs required by the other job tools.

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

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

No annotations are provided, so the description carries the full burden. It only restates the return content (stdout/stderr + state), which the output schema already covers, and says nothing about read-only safety, log truncation beyond 'tail', or permissions.

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?

A single tightly written sentence with the key payload (stdout/stderr) front-loaded and no wasted words. It is appropriately sized, though extremely terse.

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?

An output schema exists, so return values need not be explained. However, with three parameters at 0% schema coverage and no usage context against many job-related siblings, the description leaves real gaps an agent must guess at.

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 description coverage is 0%, so the schema explains none of the three parameters. The description's use of the word 'tail' hints at the tail parameter, but job_id and session remain entirely undocumented in both places.

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?

States a specific resource (background job's combined stdout/stderr) and what is returned (last tail lines plus state). It is clear about scope, though it does not explicitly distinguish itself from log-related siblings like colab_job_status or colab_log.

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?

There is no indication of when to use this tool versus colab_job_status, colab_job_list, or colab_log. The agent must infer from the name alone that this fetches log output for a job that already exists.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose key traits: execution is non-blocking, a job id is returned, and 'Jobs die if the VM is stopped' warns about job lifetime. It omits anything about working directory, environment, permissions, or how to cancel, but the async and persistence behaviors are the material ones.

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?

Three compact sentences, front-loaded with the action and example, then usage guidance, then the lifetime caveat. Every sentence adds information; no filler.

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?

An output schema exists, so return-value details are covered, and the description adequately explains the async lifecycle and how to poll. The remaining gap is the two optional parameters (name, session), which are silent in both schema and description.

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 description coverage is 0%, so the description must compensate, and it only illustrates the 'command' parameter with an example. The optional 'name' and 'session' parameters are completely unexplained — an agent cannot tell whether 'session' targets a specific VM/session or what 'name' is used for.

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?

States a specific verb and resource ('Start a shell command in the background on the VM') plus the return artifact ('return a job id'). The background/async nature meaningfully differentiates it from synchronous siblings like colab_exec and colab_run.

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?

'Use for anything longer than a few minutes' gives a clear positive trigger for this tool versus short-lived synchronous execution, and it routes the agent to colab_job_status / colab_job_logs for follow-up. It stops short of naming the tool to use instead for short commands (e.g. colab_exec), so the exclusion is implied rather than explicit.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose genuinely useful state-machine information (running, finished with exit code, cancelled, lost). However, it says nothing about whether this is a read-only, non-blocking check or whether it waits, which matters for a status-polling tool.

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?

A single tight sentence with no filler and the core purpose front-loaded. It is a noun phrase rather than a full statement, but nothing in it is wasted.

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?

An output schema exists, so return values need not be re-explained, and the state enumeration is a useful bonus. Still, with 0% parameter coverage and no usage guidance, the definition leaves real gaps for a tool that must be polled correctly.

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 description coverage is 0%, so both parameters are undocumented in the schema. The description implies job_id selects the job but gives no format or origin for it, and the optional 'session' parameter is never mentioned at all.

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 names a specific resource ('a background job') and the operation ('state'), and even enumerates the possible return states. It is clearly distinguishable from write siblings like colab_job_start or colab_job_cancel, though it does not explicitly differentiate from the adjacent colab_job_logs or colab_job_list.

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?

There is no guidance on when to call this versus colab_job_logs, colab_job_list, or colab_job_cancel, nor any mention of polling or how to obtain a job_id. The agent must infer usage entirely from the tool name.

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

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

With no annotations, the description carries the full burden and does well: it enumerates exactly what is destroyed and draws a clear safety boundary around notebooks and user data. It stops short of stating irreversibility (whether deletion is permanent or recoverable) and what 'old' means for local trash, which matters for a destructive operation.

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?

Two tight sentences, front-loaded with the action and scope, followed by the safety guarantee. Every clause earns its place and nothing is repeated.

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 no-parameter local cleanup tool with an output schema already covering return values, the description supplies what an agent needs: target scope and excluded scope. The remaining gap is the retention threshold ('old') and permanence of the deletion, both mildly relevant to a destructive call.

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?

The tool takes zero parameters, so the schema baseline of 4 applies; there is nothing parameter-level for the description to add or omit.

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 gives a concrete verb ('Delete'), a precisely bounded resource (temporary local artifacts: transfer zips, saved plots, old local trash), and an explicit negative boundary ('never touches your notebooks, data'). That negative boundary is what separates it from nearby siblings like colab_rm and colab_notebook_delete, so an agent can route correctly without opening schemas.

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?

Usage is only implied: the agent can infer this is the local disk-reclamation tool, which pairs with colab_local_footprint, but the description never states when to reach for it (e.g., 'use when local disk usage is high') nor names any alternative it should be preferred over.

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

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

With no annotations, the description carries the full behavioral burden, and it does supply the key safety fact ("Read-only") plus the categories of storage inspected. However, it omits operationally relevant traits: whether a live Colab session must exist, whether the scan is cheap or slow, and whether anything is mutated. Adequate but incomplete for a no-annotation tool.

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?

A single front-loaded sentence names the resource and its parts, with the safety qualifier deliberately placed last as a short tag. No filler and nothing repeated from the schema.

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?

An output schema exists, so return values need no explanation, and with no parameters the description has little else to cover. It is nearly complete for a simple read tool, missing only whether a running session is required to measure the local footprint.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; schema coverage is 100% and the empty object is self-explanatory. Baseline 4 applies for a no-parameter tool.

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?

Names a specific reporting action (show disk footprint) and enumerates exactly what is measured: temp files, plots, local trash, free disk, working-directory budget. The scope is clear enough to separate it from colab_local_cleanup, though it never names that sibling. The phrase "this tool keeps on your computer" is slightly ambiguous about the referent.

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?

Usage is only implied: the footprint read naturally precedes colab_local_cleanup, and "Read-only" signals a safe diagnostic, but the description never states when to call it or that cleanup is the follow-up action. No exclusions or alternatives are given despite colab_local_cleanup and colab_usage sitting directly beside it in the sibling list.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one non-obvious behavior (session omitted -> lists sessions with logs) and hints at event categories, but says nothing about ordering of entries, retention, or whether the call is side-effect free, which matters for a log-reading tool with no annotation coverage.

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?

Two short sentences, zero filler, and the primary behavior is front-loaded before the fallback case. The parenthetical on event_type adds meaning rather than padding.

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?

An output schema exists, so return-shape explanation is not needed, and all three parameters receive some semantic treatment. The remaining gap is sibling differentiation versus colab_job_logs and the full event_type vocabulary.

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 description coverage is 0%, so the description must compensate, and it largely does: `lines` = count of last entries, `session` = which session (with fallback semantics when null), and `event_type` is illustrated with concrete values (execution, file_operation). Only the exhaustive set of event_type values is left unstated.

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?

States a specific resource (a session's history/log entries) and scope (last `lines` entries), with a parenthetical clarifying what `event_type` values look like. It is clear what the tool returns, though it does not explicitly distinguish itself from the sibling colab_job_logs (job logs) beyond the word 'session'.

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 one piece of routing guidance given is behavioral: omitting `session` switches to listing sessions that have logs. That is useful, but there is no statement of when to prefer this over colab_job_logs or other log-adjacent siblings, nor any prerequisites.

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

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, yet it only states the listing scope and default path. It says nothing about whether an active session is required, whether the operation is read-only, how failures surface, or what the output looks like beyond what the output schema covers.

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?

A single, front-loaded sentence with no filler. The default path is placed inline for immediate reference, though it is arguably too terse for a tool with an undocumented session parameter.

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 simple directory-listing tool with an output schema present, the description need not explain return values. However, the undocumented 'session' parameter and complete absence of annotations or usage context leave meaningful gaps for correct invocation.

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 description coverage is 0%, so the description must compensate. It conveys the 'path' parameter indirectly via 'VM directory (default /content)', but the 'session' parameter is never mentioned, leaving one of two parameters entirely undocumented.

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?

States a specific verb (List) and resource (files in a VM directory) plus the default path, so the agent knows exactly what the tool returns. It does not, however, differentiate itself from siblings such as colab_notebook_list or colab_local_footprint, leaving the 'VM directory' scope to be inferred.

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?

There is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives. Usage is only implied by the verb 'List' and the '/content' default; nothing tells the agent how this differs from other listing tools.

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

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

No annotations are provided, so the description carries the full burden. It does disclose important behavior—'Consumes compute units until stopped'—which is genuinely useful cost/lifecycle context, plus the Colab Pro requirement for high_mem. Gaps remain: it does not say whether an existing runtime is reused, permission requirements, or what 'stopped' lifecycle entails.

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?

A single dense sentence that is front-loaded with the core action ('Create a runtime') followed by clause-by-clause parameter and constraint details. Every clause carries information; no filler.

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?

An output schema exists, so return values need not be explained, and the description covers most parameter options plus cost behavior. But the 'session' parameter is unexplained and there is no guidance on runtime lifecycle or its relationship to siblings, leaving a mutation tool with zero annotations somewhat under-specified.

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 0%, so the description must compensate, and it does so well for three of four params by enumerating gpu (T4, L4, G4, H100, A100), tpu (v5e1, v6e1), and the high_mem Pro requirement. The 'session' parameter is never mentioned, leaving one of four params undocumented in both schema and description.

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 opens with a specific verb+resource, 'Create a runtime,' which clearly identifies the action and cannot be confused with siblings like colab_stop or colab_sessions. However, it does not name or distinguish itself from the closest alternative, colab_ensure_session, so an agent must infer the boundary. Clear purpose but no explicit sibling differentiation.

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?

There is no explicit when-to-use guidance and no alternatives named. The closest thing to context is 'high_mem needs Colab Pro,' which is a prerequisite rather than a routing rule. An agent gets no help deciding between colab_new and colab_ensure_session.

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

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.

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.

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.

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.

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.

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.

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 discloses that only 'saved outputs' are cleared, but says nothing about reversibility, required permissions/session state, or side effects on a running kernel. This is thin for a 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.

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

A single front-loaded sentence with no filler; the action and its two scopes come first. It is appropriately sized for a two-parameter tool, though the 'one cell, or of all cells' clause could have been stated more crisply as a default behavior.

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?

An output schema exists, so return values need not be explained, and the core action is covered. However, with no annotations and no schema descriptions, the definition omits prerequisites and side-effect details an agent would want before invoking a destructive-output operation.

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 0%, so the description must compensate. It partially does by implying the semantic split between the optional 'cell' (clear that one cell) and its absence/null (clear all cells, matching the null default), but 'path' and the exact cell identifier format are left unexplained.

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?

States a specific verb ('Clear') and resource ('saved outputs') with the scope made explicit ('one cell, or of all cells'). It is distinguishable from siblings like colab_notebook_edit_cell or colab_notebook_delete_cell, though it never names or contrasts an alternative directly.

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 explains the two operating modes but gives no when-to-use guidance, prerequisites (e.g., does the notebook need to be open or a session active?), or pointers to alternative tools. An agent must infer context entirely.

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

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, and it omits the most consequential trait: what happens when the target file already exists and how the overwrite flag changes that. Nothing is said about permissions, failure modes, or whether the file is written immediately, leaving an agent blind on the destructive path.

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?

Two short sentences with the core action front-loaded and no filler. The second sentence exists only to document the least obvious parameter and 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?

An output schema exists, so return values need not be explained, and the cells format is covered. However, for a file-creating mutation with no annotations, the description should state the existing-file behavior and overwrite semantics; the working-directory path convention also stays implicit.

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 description coverage is 0%, so the description must compensate. It does document the cells payload shape in useful detail (list of objects with type code|markdown and source), which the schema leaves as a bare generic object, but it says nothing about path format (relative vs absolute) or the overwrite flag, so two of three parameters remain undocumented.

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 gives a specific verb and resource ("Create a local .ipynb") plus the scope ("inside the working directory"), which separates it cleanly from siblings like colab_notebook_read or colab_upload. It never names an alternative tool or clarifies the local-vs-remote distinction relative to colab_upload, so full sibling differentiation is missing.

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?

There is no when-to-use guidance: nothing says when to create a notebook here versus uploading one (colab_upload) or starting a fresh runtime (colab_new). The "local working directory" phrasing implies context but states no conditions or exclusions.

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

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

With no annotations, the description carries the full burden and does disclose the key trait: deletion is a reversible move to .colab-mcp-trash/ rather than a hard delete, which is genuinely useful safety context. However it omits what happens on a nonexistent path, whether the notebook must be closed/unsaved changes are handled, or what the trash directory lifecycle is.

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?

One sentence that front-loads the action and parenthetically disambiguates the destructive semantics. Every clause earns its place with no filler.

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?

An output schema exists so return values need not be described, and for a one-parameter soft-delete tool the core behavior is covered. The remaining gap is the undocumented single parameter, which is the only thing an agent could get wrong.

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 0% and the single 'path' parameter has no description, so the description must compensate. It implies the path refers to a local notebook inside the working directory, which is partial help, but it gives no format, relative-vs-absolute guidance, or example.

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?

States a specific verb (delete) and resource (local notebook) and immediately clarifies the mechanism as a move to trash. It is distinguishable from colab_notebook_delete_cell and colab_local_cleanup by the 'notebook' + 'local' scoping, though it never names which sibling to prefer over it.

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?

There is no guidance on when to use this versus colab_rm (which presumably deletes files) or colab_local_cleanup (which presumably purges local footprint). The agent must infer the boundary from the phrase 'local notebook' alone, and no prerequisites or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure for a destructive mutation. It says nothing about reversibility, whether the file is modified on disk, session/auth requirements, or side effects on indices of remaining cells. Only the bare action is conveyed.

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?

A single short sentence with the action front-loaded and no filler. It is efficient, though its brevity is partly a symptom of under-specification rather than disciplined concision.

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?

An output schema exists, so return values need not be described. However, for a destructive notebook-mutation tool with no annotations and 0% parameter documentation, the description omits path semantics, session requirements, and consequences of deletion — too little for an agent to invoke confidently.

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 description coverage is 0%, so the description must compensate. It clarifies that the 'cell' parameter accepts an id or an index, which is genuinely useful, but the required 'path' parameter is left completely unexplained — its format and meaning must be guessed.

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?

States a specific verb ('Delete') and resource ('one cell'), which cleanly distinguishes it from siblings like colab_notebook_edit_cell, colab_notebook_move_cell, and colab_notebook_clear_outputs. The 'by id or index' qualifier further narrows its behavior, though it doesn't name the alternatives explicitly.

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 no guidance on when to use this versus edit_cell, move_cell, or clear_outputs, nor any prerequisites (e.g., whether the notebook must be loaded or a session active). Usage must be inferred entirely from the name.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely non-obvious side effect: 'Clears that cell's stale outputs.' That is valuable behavioral context. However, it says nothing about permissions, reversibility, or behavior when the cell id/index is not found, leaving significant gaps for a 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.

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

Three tight sentences with the primary action front-loaded and zero filler. The side-effect disclosure is placed last where it belongs.

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?

An output schema exists, so return values need not be explained. The description covers purpose and the output-clearing side effect, but for a mutation tool with no annotations and 0% parameter coverage it omits permissions, error behavior, and how `path` scopes the operation.

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 description coverage is 0%, so the description must compensate. It adds real meaning for `cell` ('an id or an index') and gestures at `cell_type` ('optionally its type'), but `path` and `source` receive no explanation beyond their names. Partial compensation only.

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?

States a specific verb ('replace') and resource ('a cell's source'), which cleanly distinguishes it from add_cell, delete_cell, and move_cell by implication. It does not explicitly name a sibling or draw the boundary, so it stops short of a 5.

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?

There is no when-to-use guidance, no statement of prerequisites, and no routing to alternatives like add_cell (for new cells) or run_cell. Usage is only weakly implied by the word 'replace', which the calibration treats as no real guidance.

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

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

No annotations are provided, so the description carries the full burden. 'List' implies a safe read, but the description discloses nothing about recursion depth, pagination, ordering, or whether hidden/outside-directory files are included—behavioral traits an agent would want to know.

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?

One efficient sentence with the key resource and scope front-loaded and no wasted words. It is appropriately sized for a simple listing tool.

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?

An output schema exists, so return values need not be explained, and the tool is a simple read-only listing. Still, with zero annotation coverage and 0% schema documentation, the description leaves recursion and scope behavior unstated.

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 0% and the single 'directory' parameter (default '.') is undocumented in the schema. The phrase 'under a directory of the working directory' at least hints that the argument is relative to the working directory, adding some meaning, but format and edge cases are absent.

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?

States a specific verb (List) and resource (.ipynb files) with a directory scope. It implicitly distinguishes itself from the broader colab_ls sibling by narrowing to .ipynb files, though it never names that distinction explicitly.

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?

There is no when-to-use guidance and no mention of alternatives such as colab_ls (general file listing) or colab_notebook_read (reading notebook contents). An agent must infer the selection criteria from the name alone.

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

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. 'Move' implies a mutating reorder, but it does not disclose whether this requires an existing session, what happens with an out-of-range to_index, whether the move is persisted, or any permission needs. For a mutation tool with zero annotation coverage this is a substantial gap.

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?

It is a single short, front-loaded sentence with no filler, which is structurally clean. However, the brevity reflects under-specification rather than disciplined concision.

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?

An output schema exists, so return values need not be explained, but the description still omits any parameter meaning, mutation semantics, or usage context despite a 3-parameter, zero-coverage schema and no annotations. It is not complete enough for reliable invocation.

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 description coverage is 0% and all three parameters are bare. The sentence vaguely gestures at 'a cell' and 'a new index' but never clarifies whether 'cell' is an ID, name, or index, and never mentions 'path' at all. It fails to compensate for the documentation gap.

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 states a specific verb and resource (move a cell), which is understandable, but it essentially restates the name colab_notebook_move_cell and does not differentiate it from siblings like colab_notebook_add_cell, colab_notebook_edit_cell, or colab_notebook_delete_cell. It is viable but adds no distinguishing detail.

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?

There is no guidance on when to use this versus alternative cell operations, no mention of prerequisites, and no alternatives named. The agent must infer the context entirely.

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

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

No annotations are provided, so the description carries the full burden. It discloses the read shape and that outputs are optionally included and that large notebooks can be paged, but it never states side-effect safety, permission/auth requirements, or whether reads are non-destructive. The return format itself is covered by the output schema.

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?

Two sentences, zero waste, with the core purpose front-loaded and the paging hint appended where it belongs. Every clause 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?

With an output schema present, the description need not explain return values, and it correctly focuses on scope and paging. It is nearly complete for a read tool, missing only permission/side-effect framing that no annotation supplies.

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 description coverage is 0%, so the description must compensate. It adds real meaning for start/end (paging) and include_outputs (whether saved outputs appear), but leaves `path` and the semantics of index-based start/end bounds unexplained.

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?

States a specific verb+resource ("Show a notebook's cells") and enumerates the returned fields (index, id, type, source), which lets an agent distinguish it from mutation siblings like colab_notebook_edit_cell. It does not explicitly name the closest sibling (colab_notebook_list), so it falls short of a 5.

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 implies usage through the optional outputs flag and the paging hint ("Use start/end to page through big notebooks"), which is real guidance. However, there is no explicit when-to-use vs alternatives, no exclusion, and no routing to colab_notebook_list or colab_notebook_to_script.

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

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 does disclose valuable traits beyond the schema — ordered execution, output storage in the notebook, and the fail-fast default governed by stop_on_error. However, it is silent on session requirements, timeout behavior, cost/duration, and what happens to partially produced outputs on failure.

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?

Two sentences, zero filler. The core action and ordering constraint are front-loaded, with the scoping detail and error-handling exception following — an efficient structure for a tool of this complexity.

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?

An output schema exists, so return values need not be described. But for a 5-parameter mutation-ish tool with no annotations and 0% schema coverage, the description leaves session selection and per-cell timeout semantics entirely unexplained, which an agent needs in order to invoke it correctly.

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 description coverage is 0% across 5 parameters, so the description must compensate and it only partially does: `start` (index to begin from) and `stop_on_error` (fail-fast toggle) are given real meaning. `path`, `session`, and `timeout_per_cell` — including the notable 300s default — are never explained anywhere.

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?

Specific verb+resource: 'Run every code cell in order' clearly identifies batch notebook execution, and the parenthetical scope qualifier distinguishes it from the sibling colab_notebook_run_cell (single cell). An agent can tell from the first clause exactly what this does without opening the schema.

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?

Usage is implied by the description ('run every code cell') but the tool never states when to prefer it over colab_notebook_run_cell, colab_run, or colab_exec, nor any prerequisite such as needing an existing session/kernel. No explicit when-not guidance or named alternative appears.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose real behavior: state persists between cells, output is written into the notebook, status is reported as ok/ERROR, and displayed plots land in .colab-mcp/images/. It stops short of covering session/auth requirements, timeout behavior, or what happens on error.

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?

Three short, front-loaded sentences with no filler: the action, the state-persistence caveat, the status report, and the artifact location each earn their 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?

An output schema exists so return values need not be described, and the description usefully adds status and artifact-path detail anyway. However, with zero schema description coverage and no annotations, the undocumented session and timeout parameters leave the definition short of what an agent needs to invoke it confidently.

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 description coverage is 0%, so the description must explain the four parameters, yet it only gestures at 'cell' (a code cell) and mentions no meaning for path, session, or timeout (which defaults to 300s). Three of four parameters remain opaque to the agent.

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?

States a specific verb and resource ('Run ONE code cell on the runtime') plus the side effect of persisting output into the notebook. The emphasis on ONE implicitly distinguishes it from the sibling colab_notebook_run_all, though no sibling is named explicitly.

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?

Usage is implied rather than stated: running a single cell with persistent state suggests pairing with colab_notebook_run_all or colab_exec, but neither alternative is named nor is a when-not condition given. An agent must infer the routing from the tool names alone.

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

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 transformation semantics (markdown to comments, !/% lines commented out) and the two output modes (write file vs return text). However, it omits side-effect details such as overwrite behavior when out_path exists and error handling for invalid notebooks, leaving meaningful gaps for an unannotated mutation-capable tool.

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?

Three short clauses, front-loaded with the core purpose, followed by transformation detail and the mode switch. Every sentence earns its place with no filler.

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?

An output schema exists, so return values needn't be described, and the description correctly notes the text-return case. Combined with the transformation rules, it is largely sufficient for correct invocation; only edge cases like overwriting an existing out_path are unaddressed.

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 0%, so the description must compensate. It does explain out_path clearly ('writes the file; otherwise returns the text'), which resolves the genuine ambiguity of the optional parameter. The required path parameter receives no explicit semantic description, so compensation is partial.

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?

States a specific verb and resource: 'Convert a notebook to a .py script', with immediate detail on the transformation rules. It is clearly distinguishable from read/list/navigation siblings. It stops short of an explicit sibling contrast, which is only a minor gap given no other sibling performs conversion.

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?

'Handy before colab_run' gives concrete usage context, and the out_path conditional tells the agent which mode to pick. There is no explicit when-not-to-use guidance or mention of alternatives, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does disclose the key destructive effect (all Python variables cleared) alongside what is preserved (VM and files) — exactly the trade-off an agent needs. It stops short of saying whether in-flight execution/jobs are interrupted or what auth/session ownership is required.

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?

One front-loaded sentence with the verb first and the destructive/preserving consequences trailing. Nothing redundant; every clause adds information.

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?

An output schema exists, so return values need no prose, and the core side effects are covered. Still, for a mutation-style tool with zero annotation coverage, the unstated behavior of the null-defaulted session parameter and whether restart interrupts running cells leaves an agent with real gaps.

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 0% and the single 'session' parameter is optional with a null default, so the schema explains nothing. The description refers to 'a session' but never says which session is targeted when the argument is omitted, nor what the session identifier format is, leaving the only parameter ambiguous.

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?

States a specific verb (restart) and resource (Jupyter kernel of a session), and immediately scopes it against the obvious sibling behavior: variables are cleared but the VM and files persist, which separates it from colab_stop (which would kill the runtime). An agent can pick this over colab_stop, colab_new, or colab_exec without opening any schema.

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?

Usage is only implied: by saying variables are cleared while files persist, it hints at 'use when you want a clean Python state without losing work.' It never names an alternative tool or an explicit when-not condition (e.g., 'to free the VM entirely, use colab_stop'), so the routing decision is left partly to inference.

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

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

With no annotations, the description must carry the safety profile. It usefully discloses VM-only scoping and a root-like path refusal, but omits irreversibility, permissions, missing-file behavior, and session semantics. This is minimum viable transparency for a destructive tool but leaves notable gaps.

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?

Two short sentences, front-loaded with the action and scope, then the safety constraint. No filler; every clause adds information.

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 destructive VM file operation with two undocumented input parameters and no annotations, the description leaves key invocation details unstated, especially session selection and path format. The output schema reduces the need to explain return values, but the input-side gaps remain significant.

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 description coverage is 0%, yet the description never names or explains either parameter. The required path parameter is only implicit in 'file', and the optional session parameter is entirely absent, so it does not compensate for the schema gap.

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?

States a specific verb, 'Delete', and resource, 'ONE file on the VM', and explicitly scopes it away from the user's computer. It does not name a sibling alternative, but an agent can distinguish it as the VM file-deletion tool.

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 implies when to use it (deleting a file on the VM) and gives a when-not constraint (not the user's computer; refuses root-like paths). It does not explain when to choose this over sibling tools such as colab_notebook_delete or colab_local_cleanup, nor does it describe session handling.

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

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

With no annotations, the description carries full behavioral burden, and it does disclose the important lifecycle (allocate fresh VM, run, release, or keep with keep=true) and the working-directory constraint. It omits gpu/high_mem effects, timeout behavior, and what happens to the VM on script failure, so the disclosure is partial rather than complete.

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?

A single dense sentence that front-loads the execution model and never wastes a clause; every phrase (fresh VM, local script, working directory, keep=true) carries information.

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?

An output schema exists so return values need no explanation, and the lifecycle is covered. But for a resource-allocating mutation with zero annotation coverage and 6 undocumented parameters, the agent still lacks guidance on gpu selection, timeout semantics, and failure behavior.

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 description coverage is 0% across 6 parameters, so the description must compensate. It adds real meaning for script ('local', 'inside the working directory'), args (passed to the script), and keep (retains the VM), but gpu, timeout, and high_mem are left entirely undocumented in both schema and description.

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?

States a specific verb and resource (run a local script) and qualifies the execution model as a 'one-shot job' that allocates a fresh VM and releases it. This distinguishes it from persistent-session tools like colab_exec or the colab_job_* family, though it never names a sibling explicitly.

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?

'One-shot job' implicitly signals when this is appropriate versus session- or job-based alternatives, and 'keep=true' hints at the persistent path. However, there is no explicit when-to-use/when-not statement or named alternative (e.g. colab_exec vs colab_job_start), so the agent must infer routing.

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

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

With no annotations, the description carries the full behavioral burden. 'Report' implies a non-destructive read and '(if any)' hints at a conditionally-present GPU field, which is useful. However, it does not disclose session prerequisites, auth requirements, or whether it spins up a runtime.

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?

A single well-formed sentence with the resource scope front-loaded and zero wasted words. The parenthetical GPU qualifier adds precision without padding.

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?

An output schema exists, so return-value explanation is rightly omitted, and for a read-only info tool the description is nearly sufficient. The unexplained 'session' parameter and absent guidance on session prerequisites leave a real gap.

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 description coverage is 0% and the single 'session' parameter has no documentation in either the schema or the description. Since coverage is below 50%, the description should compensate but does not mention the parameter at all.

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 uses a specific verb ('Report') and enumerates exactly what is reported: Python version, CPUs, RAM, free disk, and GPU. This lets an agent distinguish it from generic siblings like colab_status or colab_usage. It stops short of explicitly naming which sibling to use instead, so it does not reach a 5.

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?

There is no when-to-use guidance, no prerequisites (e.g., whether an active session is required), and no mention of alternatives such as colab_status or colab_usage. The agent must infer context entirely on its own.

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

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

With no annotations at all, the description carries the full behavioral burden. It implies a read-only listing of 'active' entities and hints at an auth dependency via the sign-in check, which is useful, but it does not state whether it requires prior authentication, what happens when signed out, or whether the call has any side effects.

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?

Two short, front-loaded sentences with essentially no filler. The 'Also...' sentence is slightly tangential and could have been merged or dropped, but the whole description is tightly sized for a no-argument listing tool.

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?

The tool is simple: no parameters, an output schema that documents the return shape, and no annotations to reconcile. The description covers purpose and one extra use case, which is close to sufficient, though a caveat about needing Google sign-in or the difference from colab_status would have closed the remaining gap.

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?

The schema takes zero parameters, so there is no parameter semantics for the description to explain. Baseline of 4 applies; nothing is missing or misleading on this dimension.

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?

Specific verb + resource: "List active Colab runtimes (sessions)" clearly states what the tool does and clarifies the ambiguous term 'sessions' as runtimes. However, it never distinguishes itself from close siblings such as colab_status or colab_runtime_info, which an agent could easily confuse it with.

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 second sentence adds a secondary use case (verifying Google sign-in works), which implies when the tool is handy. But there is no explicit when-to-use/when-not guidance and no naming of alternatives among the ~40 Colab siblings, so the agent must infer the boundary itself.

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

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

No annotations are provided, so the description carries the full burden. 'Show' implies a non-mutating read, and the default-to-active-session behavior is disclosed, but there is no mention of permissions, what happens when no session exists, or any error/rate-limit behavior.

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?

A single front-loaded sentence with no filler; the core resource list comes first and the default behavior second. It borders on under-specification rather than being padded, but as written it is tight and readable.

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?

An output schema exists, so return values need not be explained, and the description covers what is shown. For a tool in a namespace crowded with similar status/info tools, the absence of any positioning against colab_runtime_info, colab_sessions, or colab_usage leaves a real gap.

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?

The schema documents the single 'session' parameter only structurally (string|null, default null, 0% description coverage). The description partially compensates by explaining that omitting it targets 'the only active one', but it adds no format, naming, or identifier conventions for the session value.

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?

States a specific verb ('Show') and concrete resources (hardware, machine shape, state of a session), so an agent knows this is a status/read tool rather than an action tool. It does not name or differentiate itself from close siblings such as colab_runtime_info, colab_sessions, or colab_usage, which an agent could easily confuse it with.

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 parenthetical '(or the only active one)' clarifies the fallback when the session argument is omitted, which is genuinely useful. However, there is no explicit guidance on when to pick this over colab_runtime_info, colab_sessions, or colab_usage; usage must be inferred from the wording.

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

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

With no annotations, the description carries the full burden and delivers the key behavioral trait: non-downloaded files are permanently lost, plus the compute-unit cost effect. It does not state permission requirements or behavior when no session exists, keeping it short of a 5.

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?

Two tight fragments with the core action front-loaded and the destructive warning appended. No filler, though the parenthetical could integrate more smoothly.

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?

An output schema exists, so return values need not be explained, and the destructive side effect is covered. However the optional `session` parameter is left undocumented, which is a real gap for invoking the tool correctly.

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 0% and the single `session` parameter (optional, defaults to null) is never mentioned in the description. The agent gets no hint about what the parameter does or how the no-argument case is resolved.

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?

States a specific verb+resource ("Stop a session and release the VM") that cleanly distinguishes the terminal stop action from siblings like colab_restart_kernel or colab_job_cancel. It does not name an alternative explicitly, but the action is unambiguous.

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?

Usage is implied via the cost rationale ("stops consuming compute units"), which signals when an agent should call it, but there is no explicit when-to-use vs alternative guidance or prerequisite (e.g., requires an active session).

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

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

With no annotations, the description carries the full burden, and it does disclose a real constraint: the COLAB_MCP_MAX_UPLOAD_MB limit (default 100MB) and the working-directory restriction. It omits overwrite behavior, authentication, and transfer-failure semantics, but the size-limit disclosure is genuinely useful context.

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?

Two tight sentences: the core action and example come first, the caveat and alternative routing second. No wasted phrasing.

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?

An output schema exists, so return values need not be explained. However, for a 3-parameter tool with zero schema description coverage, the description leaves 'session' entirely undocumented and gives no explicit path-format guidance for local_path.

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 0%, so the description must compensate. It clarifies remote_path with a concrete example ('/content/data.csv') and implies local_path is relative to the working directory, but the 'session' parameter is never mentioned and local_path format is left to inference.

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?

States a specific verb (upload), a precise resource (one local file inside the working directory), and the destination (the VM). The word 'one' implicitly distinguishes it from the colab_upload_dir sibling, and the remote_path example makes the resource concrete.

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?

Explicitly routes large-data cases away from this tool, naming the alternatives (colab_exec / colab_job_start) and the trigger (COLAB_MCP_MAX_UPLOAD_MB limit). It does not explicitly state how this differs from colab_upload_dir for multi-file cases, so the sibling routing is only implied.

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

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

With no annotations, the description carries the burden and does useful work: it discloses that the folder is zipped, extracted at remote_dir, and that .git, caches, symlinks and secret files are skipped. It omits overwrite behavior, size limits, and error semantics, but the skip list is substantive behavioral disclosure.

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?

Two tight sentences with no filler, and the core action is front-loaded ahead of the skip-list detail. Every clause 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?

An output schema exists, so return values need not be described. For a mutation tool with no annotations, the description covers packaging and skip behavior adequately; only overwrite/collision semantics are missing.

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 description coverage is 0%, so the description must compensate. It clarifies local_dir ('whole local folder ... inside the working directory') and remote_dir ('extracted at remote_dir'), but the session parameter is never addressed, leaving one of three parameters undocumented in both schema and description.

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?

States a specific verb and resource ('Upload a whole local folder ... to the VM as one zip'), and the 'whole folder' phrasing implicitly separates it from the single-file colab_upload sibling. It does not name that sibling, so differentiation is inferred rather than explicit.

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 parenthetical '(inside the working directory)' gives a precondition for use, but there is no explicit when-to-use/when-not guidance and no reference to colab_upload for single files or colab_download_dir as the reverse operation. Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses one non-obvious trait ('does not open a browser'), clarifying this is a pure read that returns a URL rather than launching anything. However, it says nothing about auth/permission needs, session requirements, or error behavior when no session exists.

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?

One sentence, front-loaded with the action and resource, with the parenthetical caveat placed where it is most useful. No filler.

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?

An output schema exists, so return-value explanation is unnecessary. The main residual gap is the undocumented 'session' parameter, but for a simple URL-printing tool the description is otherwise adequate.

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?

The single 'session' parameter has 0% schema description coverage and is not mentioned in the description at all. The description therefore gives no guidance on what the parameter does or what the default (null) implies, failing to compensate for the coverage gap.

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?

States a specific verb ('Print') and a precise resource ('the browser URL that attaches the Colab UI to this session'). It is clearly distinct from siblings like colab_status or colab_runtime_info, though it does not explicitly name what those alternatives return.

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?

Usage is only implied: an agent can infer it should be called when the user needs a link to open the Colab UI in a browser. There is no explicit when-to-use statement, no mention of prerequisites (e.g. an active session), and no comparison to sibling tools.

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

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

No annotations are provided, so the description carries the full burden; 'Show' implies a non-mutating read and it names exactly what is reported (balance and burn rate), which is the core behavior for a query tool. It says nothing about whether the read is live vs cached, whether units are shared across sessions, or whether the call itself has any cost, leaving meaningful gaps for a definition with zero annotation support.

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?

A single front-loaded sentence stating the resource and the two values returned, with no filler, hedging, or restated tool name. Every word 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?

An output schema exists, so the description need not explain return values, and with no parameters there is nothing else to document structurally. It is nearly complete, missing only the usage context that would help an agent decide between this and other status tools.

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?

The tool takes zero parameters, so per the rubric the baseline is 4 and there is no parameter semantics to compensate for. Schema description coverage is effectively 100% by vacuity.

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 names a specific verb+resource pair ('Show the account's compute-unit balance and current burn rate'), which is materially distinct from quota-free siblings like colab_status or colab_runtime_info. It never explicitly says how it differs from those adjacent status tools, so it lands at clear-but-undifferentiated rather than top-tier.

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?

There is no guidance on when an agent should call this versus colab_status, colab_runtime_info, or colab_drive_status, all of which could plausibly be consulted for account state. The purpose implies a billing/quota-check use case but nothing states it, and no prerequisites or exclusions are given.

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