SassyMCP

Official

Overview Schema Source Related Servers Discussions Admin

sassy_tar

Idempotent

Create a tar archive from a file or directory, with gz, bz2, xz, or no compression. Sensitive files are flagged in a warning and audit-logged.

Instructions

Mutating: writes a new tar archive to disk. Creates a tar from a file or directory path in source; directory contents are stored under the top-level directory name. compress (default gz) accepts gz, bz2, xz, or none, and any other value returns an error. output defaults to the source path plus .tar.gz, .tar.bz2, .tar.xz, or .tar according to compress. Sensitive members are not blocked (full-directory backups must keep working): if any archived file matches the sensitive-read denylist (SSH keys, credential stores, ...), the archive is still created but the result carries a 'warning' field listing them and the event is audit-logged. Returns the created path, a file count, and the archive size in bytes. There is no password option, unlike sassy_unzip. Use it to bundle directories for transport or backup; use sassy_untar to extract what it creates.

Input Schema

TableJSON Schema

Name	Required	Default
`output`	No
`source`	Yes
`compress`	No	gz

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.15.1Sep 18, 2026

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "title": "Result",
-    "type": "string"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"sassy_tarOutput"New value: +"sassy_tarDictOutput"

First observedv0.1.0Jul 31, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, but the description adds critical context: it confirms mutation, explains the sensitive-member behavior (archive still created, warning field, audit log), and details output naming conventions and error conditions for invalid compress values. No contradiction with 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 information-dense but every sentence serves a purpose: purpose, parameter behavior, sensitive-file handling, return values, and usage guidance. It is front-loaded with the core action and then expands on details. Slightly long but not wasteful; a 4 reflects the balance between completeness and brevity.

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 tool with 3 parameters, an output schema, and annotations, the description covers all necessary aspects: exact inputs, output path logic, return fields (path, count, size), error handling, sensitive-file policy, and how it relates to siblings. An agent can invoke it correctly without any additional inference.

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 fully compensates by explaining each parameter: source (file or directory path), compress (accepted values gz, bz2, xz, none, with default gz and error on other values), and output (default path construction based on compress). This goes beyond schema field names to give meaningful usage semantics.

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 (creates/writes), resource (tar archive), and behavior (from file or directory path). It distinguishes itself from siblings like sassy_untar and sassy_zip by describing its role as bundling for transport/backup and explicitly noting it is not sassy_unzip.

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?

Explicitly states when to use it ('Use it to bundle directories for transport or backup') and provides the alternative ('use sassy_untar to extract what it creates'). Also mentions a key difference from sassy_unzip (no password option), which helps agent choose correctly.

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

Deploy Server