Skip to main content
Glama

usb_drive_delete

Delete files or folders on the Virtual USB Drive; set recursive=true to remove non-empty folders and their contents.

Instructions

Delete a file or folder on the Virtual USB Drive. Folders that are not empty are only deleted with recursive=true (the firmware deletes folders including their contents).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
recursiveNo
remote_pathYes
switch_to_kvmNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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 destructive semantics of recursive deletion (folders and their contents are removed by firmware). However, it never states whether deletion is permanent/irreversible, what permissions or mounted-state prerequisites apply, or how errors surface, which are important for an irreversible operation.

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

Conciseness5/5

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

Two tight sentences: the first front-loads the core verb and resource, the second adds only the conditional constraint that changes how the call must be made. No filler or restated metadata.

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

Completeness3/5

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

An output schema exists, so return values need not be described, and the recursive constraint is covered. For an irreversible delete tool with zero annotations and a 0%-documented schema, the missing information about permanence, prerequisites, and the switch_to_kvm parameter leaves real gaps.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must fill the gap for all three parameters. It explains 'recursive' well (including firmware behavior on non-empty folders) but says nothing about 'remote_path' format or the non-obvious 'switch_to_kvm' flag, leaving two of three parameters undocumented anywhere.

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

Purpose4/5

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

The description uses a specific verb ('Delete') on a specific resource ('a file or folder on the Virtual USB Drive'), which is unambiguous and clearly distinct from the upload/download/list siblings. It stops short of naming an alternative tool or scoping the operation further, so it is clear but not maximally differentiating.

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

Usage Guidelines4/5

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

It gives a concrete usage rule for the recursive case: non-empty folders require recursive=true, and explains what the firmware does in that mode. There is no explicit when-not-to-use guidance or named alternative (e.g., unmount before deleting), so it is clear context rather than full routing guidance.

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