Skip to main content
Glama
jansc4
by jansc4

Execute file operation

files_execute_op
Destructive

Execute one file delete/move operation when confirm='EXECUTE' is provided. Logs every action, and works with for_each to run many operations under a single confirmation.

Instructions

Executes a SINGLE delete/move operation. Requires confirm='EXECUTE' — without it, nothing happens. Logs every operation to log_path. Use with for_each (confirm and log_path shared in args across all items) to run on many files in one pipeline step — a single 'EXECUTE' in the step still gates the whole series, just like it used to gate the whole batch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dstNo
srcYes
actionYes
confirmYes
log_pathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond destructiveHint=true, the description discloses the confirmation gate, the no-op behavior without EXECUTE, logging to log_path, and the batch gating semantics. This is safety-relevant behavior that annotations alone do not provide, and there is no contradiction.

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

Conciseness4/5

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

Three sentences with the most important scoping and safety information front-loaded. The phrase 'just like it used to gate the whole batch' is slightly vague but does not add meaningful bloat.

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

Completeness4/5

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

With an output schema present, return-value details are covered. The description adequately covers the operation, confirmation requirement, logging side effect, and for_each batching. It could be more complete by explicitly routing to files_preview_op for non-destructive checks and clarifying src/dst roles.

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

Parameters3/5

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

With 0% schema coverage, the description compensates for confirm (must equal 'EXECUTE'), log_path (receives logs), and action (delete/move). However, src and dst are not explicitly defined, and action values are not enumerated despite no enums in the schema, so some parameter semantics are still left to inference.

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

Purpose5/5

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

The description states a specific verb and resource: 'Executes a SINGLE delete/move operation.' It clearly distinguishes this from a batch or preview tool, and the contrast with the sibling files_preview_op is implicit but strong.

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 explicitly says confirm='EXECUTE' is required and nothing happens without it, and it instructs using for_each for many files with shared confirm/log_path. It gives clear usage context, though it does not explicitly name files_preview_op as the safe non-executing alternative.

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