Skip to main content
Glama
Sign In
sangingeum

filekeeper-mcp

by sangingeum
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

directory_delete

Destructive

Delete a directory inside a registered workspace with dry-run preview, recursive confirmation for non-empty folders, and undo support.

Instructions

Delete one directory and return operation_id and undo_available. Destructive.

    A non-empty directory requires recursive true and confirm_recursive true;
    one without the other is refused before anything is touched. The scope is
    exactly the named subtree inside the selected workspace root — this tool
    cannot delete outside it, and Filekeeper's own .filekeeper/ state
    directory is refused. dry_run lists what would be removed and deletes
    nothing. Otherwise the whole tree is recorded as one operation and is
    undoable.

Input Schema

NameRequiredDescriptionDefault
pathYes
dry_runNo
recursiveNo
confirm_recursiveNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, but the description adds substantial context beyond them: scope is confined to the named subtree in the workspace root, the state directory is refused, mutually-dependent guard flags are validated before anything is touched, and the whole tree is recorded as one undoable operation. Those are exactly the behavioral facts an agent needs before mutating.

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-loads the action, the return values and the destructive warning in the first line, then layers guards, scope and undo semantics. Every sentence adds an operational fact; there is no restatement of the title or padding.

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

Completeness5/5

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

For a destructive 4-parameter mutation with no output schema, the description names the return fields, the refusal conditions, the scope boundary and undoability. An agent could call this correctly and safely without reading anything else.

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 description coverage is 0%, so the description must carry the parameters and it largely does: it explains the interplay of recursive and confirm_recursive, and the semantics of dry_run (lists, deletes nothing). Only 'path' is left implicit via the workspace-root scope wording, with no format or relative-vs-absolute guidance.

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?

Opens with a specific verb+resource ('Delete one directory') and immediately names the return values (operation_id, undo_available) and the destructive nature. A single-directory subtree scope plus the '.filekeeper/ state directory is refused' rule clearly separates it from file_delete and directory_create among the siblings.

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?

Explicitly states the condition for recursion ('a non-empty directory requires recursive true and confirm_recursive true; one without the other is refused') and prescribes dry_run for previewing. It does not name a sibling alternative (file_delete vs directory_delete), so it stops short of full alternative routing.

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

Deploy Server

Other Tools