SapperMCP

Overview Schema Source Related Servers Discussions Admin

Delete Path

delete_path

Deletes files or directories; use recursive for directory removal. Destructive and irreversible; protected system paths are refused.

Instructions

Delete a file or directory. Directories need recursive=True. Destructive: cannot be undone. Protected system paths are refused.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "delete_path"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes
`sudo`	No
`recursive`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.1/5.0

Behavior4/5

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 discloses destructiveness, irreversibility, and a refusal condition for protected paths. It stops short of explaining what the sudo flag does or what happens when a path does not exist, leaving a real gap on the privilege-escalation behavior.

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?

Three short sentences, front-loaded with the action, then the conditional requirement, then the risk warning. No filler and nothing buried.

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?

An output schema exists, so return values need no explanation, and the destructive/refusal semantics are covered. The missing piece is the sudo parameter's semantics and permissions implications, which matters for a delete operation on a tool with zero annotation coverage.

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 coverage is 0%, so the description must define all three parameters. It partially explains recursive (required for directories) but says nothing about sudo, a meaningful privilege-escalation flag, nor about whether path must be absolute or relative. Only one of three parameters gains any meaning beyond the bare schema.

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 ('a file or directory'), and immediately splits the two cases by noting directories require recursive=True. An agent can tell at a glance that this removes filesystem entries, unlike siblings such as copy_path or move_path.

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?

Gives clear conditional guidance: use recursive for directories, and expect refusal on protected system paths. There is no true alternative delete tool among the siblings to route away from, so the absence of explicit exclusions is minor.

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

Deploy Server