Loading ToolBench
MCP server that gives AI agents the ability to compress and decompress any data. First compression MCP server. 10x smaller data, near-zero overhead.
mcp-compress has 8 tools with basic descriptions and schemas present in code. However, the implementation has significant definition quality gaps: (1) descriptions are minimal (10-50 chars), providing little actionable context for LLM tool selection; (2) parameter schemas exist but lack depth, no enums for algorithm choices, no ranges for bits parameter, no validation guidance; (3) no output schemas documented, forcing LLMs to guess what compress() returns; (4) error handling is present in code but not surfaced in tool definitions; (5) tool composition is reasonable (single responsibilities) but parameter naming could be more explicit (e.g., 'data' is vague, should be 'raw_data', 'text_content', or 'json_object'). The quantize/dequantize tools have type unions in descriptions ('string|array') but no formal schema constraints. Tools are directly visible in index.js via server.setRequestHandler(), so no inference penalty applies. Baseline: production tools average 194 chars per description (p10=34, p90=392); these average ~35 chars. Production schemas include enums for categorical parameters and ranges for numerics, this server has neither.
Show compressibility, best algorithm, estimated savings
Compress text/JSON/CSV data (zstd, gzip, lz4, brotli)
Decompress back to original
Restore quantized numerical data compressed with TurboQuant
Compress numerical data using TurboQuant extreme numerical compression (lossy)
Decompress and retrieve from disk
Show compression stats across all stored data
Descriptions are critically short (15-40 chars) and lack actionable context. 'Decompress back to original' tells an LLM nothing about when to call it vs. compress, what formats it accepts, or what to do if decompression fails. Baseline: production tools average 194 chars; 90% are 34-392 chars.
No output schemas documented. Tools like compress() return structured data (e.g., {compressed_data, original_size, savings_percent, algorithm_used}) but callers have no visibility into the shape. This forces LLMs to infer output structure and risks hallucinated field access.
Algorithm selection (compress, decompress, quantize) lacks enum constraints. Parameter 'algorithm' accepts 'auto', 'gzip', 'brotli', 'deflate', 'turboquant' but is defined as free-form string. No enum = LLMs can hallucinate invalid algorithms like 'lz77' or 'snappy'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Compress and store to disk with metadata
Parameter 'bits' in quantize() has no range constraint. Code accepts 1-32 bits, but schema shows 'default: 4' with no min/max. An LLM could pass bits=1000, causing memory/performance issues. Should declare minimum 1, maximum 32.
Parameter 'numbers' in quantize has type union 'string|array' but no guidance on format. Description mentions 'JSON array or comma-separated values' but these are in error-handling fallback code, not in tool schema. LLM cannot discover valid formats from schema alone.
store/retrieve tools interact with user filesystem (~/.mcp-compress). No tool description explains file path semantics, ID constraints (length, charset), or quota limits. An LLM could pass a 1GB string as 'data' with no awareness of storage consequences.
decompress() parameter 'data' accepts both 'base64 or raw' but provides no clear schema. LLMs must guess whether to pass base64-encoded strings, hex strings, or raw bytes. Should clarify: 'base64-encoded compressed data (string)'.
Tool composition uses generic parameter name 'data' across compress, decompress, analyze, store. Baseline recommends verb_noun + type suffix (e.g., 'raw_text', 'json_object', 'csv_content') to disambiguate. 'data' is ambiguous, could be text, binary, CSV, JSON, etc.
No error recovery guidance in tool definitions. Code contains error handling (e.g., 'Could not parse numbers'), but tool descriptions do not explain: (1) which inputs are validated? (2) what does failure look like? (3) what should LLM do next? E.g., analyze() should say 'Call compress() if compressibility > 50%'.