Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

by KitchenSink4AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Manage Backups

manage_backups
Destructive

List, restore, purge, or snapshot automatic Excel workbook backups to recover from corruption or overwrites, with undoable restores and orphan cleanup.

Instructions

Manage the automatic backups in the hidden .ks4xl-backups folder next to each mutated workbook: two rotating slots per file, prev (state before the most recent mutation) and anchor (session start). action='list': slot files with sizes and mtimes plus orphaned slot folders; give path for one workbook or directory for a folder. action='restore': overwrite path with source 'prev' or 'anchor'; the current content rotates into prev FIRST so a restore is itself undoable, the payload is validated as a real workbook before the atomic replace, and files open in Excel refuse. action='purge': delete backups; scope is 'orphans' (slot folders whose workbook is gone) or 'slots' (one workbook's pair); dry_run defaults to TRUE and only reports. action='snapshot': save a permanent DTG-stamped copy, YYYYMMDD_HHMM_, optional label and dest_dir; snapshots are never rotated and no purge scope touches them. LIMIT, stated loudly: prev holds the state before the LAST mutation this server made, so damage that lands AFTER the last save (crash, disk, another program) costs that final edit; only a snapshot habit covers it. Lost or corrupt file? get_workflows task='recover-workbook' is the walkthrough.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
labelNo
scopeNo
actionYes
sourceNo
dry_runNo
dest_dirNo
directoryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
  2. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

The annotations only set destructiveHint=true; the description far exceeds that by disclosing exactly what each destructive path does: restore rotates current content into prev first (making it undoable), validates payloads before atomic replace, refuses files open in Excel, purge honors dry_run=TRUE default, and snapshots are never touched by rotation or purge. This is rich behavioral disclosure with zero contradiction against annotations.

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?

The description is long (~250 words) but every sentence earns its place given 4 modes and 8 params. It is front-loaded with the storage model and organized action-by-action, with the LIMIT warning and cross-reference placed last. The only shortfall is a single dense paragraph rather than scannable structure, and minor repetition of the folder name.

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?

For a destructive, multi-mode tool with no output schema, the description covers every parameter, every action's side effects, the fundamental limitation, and the recover-workflow alternative. The only omissions are explicit return-value formats for actions like list (it names fields — sizes, mtimes — but not the response shape), which is marginal against the overall exhaustiveness.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden for all 8 parameters and discharges it completely: path (workbook vs directory), source (prev/anchor), scope (orphans/slots), dry_run (defaults TRUE, only reports), label/dest_dir (snapshot naming), and directory (folder listing). Every parameter's meaning and format is covered in prose.

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 resource (automatic backups in the hidden .ks4xl-backups folder with rotating prev/anchor slots) and fully enumerates the four actions (list, restore, purge, snapshot). No sibling tool handles backup management, so it is cleanly distinguished from every sibling merely by resource and verb.

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?

Goes beyond stating when to use it — it explains each action's mode with its governing parameters (list takes path or directory; restore takes source prev/anchor; purge takes scope orphans/slots and dry_run default; snapshot takes label/dest_dir). It also gives an explicit exclusion: the LIMIT paragraph warns what the tool cannot recover, and routes to the sibling get_workflows task='recover-workbook' for that case.

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