Skip to main content
Glama
N0moreher0
by N0moreher0

Delete path

project_delete_path
DestructiveIdempotent

Delete a file or directory from the workspace; set recursive=true to remove a directory and its contents. Use only when the path is confirmed, because deletion cannot be undone.

Instructions

Delete a file or directory (directories require recursive=true). Use when: a file/directory must be deleted entirely; the path is confirmed. Avoid when: you only need to change the content (write/edit). This op is not undoable. Speed: fast; clears the read/list/search cache. Output: path_deleted: entries_deleted, bytes_deleted. Batch-safe: no

Input Schema

NameRequiredDescriptionDefault
recursiveNo
relative_pathYesPath inside the workspace (relative, or absolute inside the workspace)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known; the description still adds value by stating the operation is not undoable, that it clears the read/list/search cache, and that it is not batch-safe. It stops short of describing error behavior (missing path, recursive flag misuse on a file), which matters for a destructive tool.

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?

Front-loaded with the action, then structured labeled lines for usage, avoidance, speed, output, and batch safety. Every line carries distinct information with no repetition of schema or annotations.

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?

Covers the destructive/irreversible nature, the cache side effect, and the return shape despite there being no output schema, which is exactly what an agent needs. Missing only details about failure paths (nonexistent path, permission errors) since no error schema exists.

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

Parameters4/5

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

Schema coverage is only 50% — relative_path is documented in the schema but recursive has no description there. The description compensates by explaining recursive only in the context of directories, though it doesn't state the default or what happens if omitted on a directory.

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?

States a specific verb (Delete) and resource (file or directory) and immediately qualifies the directory case with recursive=true. It is clearly distinguishable from siblings such as project_write_file, project_edit_file, and project_create_directory.

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

Usage Guidelines5/5

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

Uses explicit 'Use when' and 'Avoid when' clauses and names the alternative operations (write/edit) that should be chosen instead. The condition for selecting this tool is unambiguous.

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