Provides capabilities for lossless compression and decompression of Markdown documents to save space while maintaining data integrity.
The first MCP server for data compression. Gives any AI agent the ability to compress, decompress, analyze, and store data.
10,000+ MCP servers exist. Zero for compression. This is the first.
Zero dependencies. Pure Node.js. Lossless round-trip. Auto-picks the best algorithm.
Real results on real data types:
Data Type | Original | Compressed | Ratio | Saved |
Markdown docs (15KB) | 31.2 KB | 0.5 KB | 60.7x | 98.4% |
Repeated config (2KB) | 5.4 KB | 0.1 KB | 51.9x | 98.1% |
SQL query results (8KB) | 18.9 KB | 0.6 KB | 30.4x | 96.7% |
Log files (20KB) | 33.3 KB | 1.7 KB | 19.9x | 95.0% |
JSON API response (10KB) | 26.7 KB | 2.6 KB | 10.2x | 90.2% |
Time-series prices (4KB) | 20.5 KB | 3.0 KB | 6.9x | 85.5% |
CSV data (5KB) | 8.1 KB | 2.4 KB | 3.4x | 70.5% |
Every compression is lossless — decompress returns the exact original, byte-for-byte.
Related MCP server: shorthand-mem
Add to ~/.claude/settings.json:
{
"mcpServers": {
"compress": {
"command": "npx",
"args": ["-y", "mcp-compress"]
}
}
}npx mcp-compressSpeaks MCP protocol over stdio. Works with any MCP-compatible AI agent.
git clone https://github.com/ShipItAndPray/mcp-compress.git
cd mcp-compress
node index.js7 tools available to any connected agent:
Tool | What it does |
| Compress text/JSON/CSV. Auto-picks best algorithm (gzip, brotli, deflate). Returns base64 + ratio. |
| Decompress back to original. Lossless round-trip verified. |
| Shannon entropy, compressibility rating, all algorithms compared, recommendation. |
| Compress and persist to disk with a key. Compressed key-value store for agents. |
| Decompress and return stored data by key. |
| List all stored items with sizes and compression ratios. |
| Total items stored, bytes saved, overall compression ratio. |
Compress a large API response:
compress(data: "<10KB JSON>", algorithm: "auto")
→ { ratio: "10.2x", saved_percent: "90.2%", algorithm: "brotli" }Analyze before compressing:
analyze(data: "<your data>")
→ { compressibility: "HIGH", best_ratio: "30.4x", recommendation: "compress everything" }Store data for later retrieval:
store(data: "<research notes>", name: "market-analysis")
→ { key: "market-analysis", ratio: "8.3x", saved: "12,450 bytes" }
retrieve(key: "market-analysis")
→ { data: "<original research notes>" }Check what you've stored:
stats()
→ { stored_items: 14, total_saved_bytes: 284102, overall_ratio: "11.2x" }AI agents generate and consume massive amounts of text — API responses, code, docs, data
Context windows are expensive. Compressed storage = more data in less space = lower cost.
MCP is the standard protocol for AI agent tools. 10,000+ servers, none for compression.
Auto-algorithm selection means the agent doesn't need to know anything about compression — it just works.
Auto-algorithm selection — tests gzip, brotli, and deflate on your data, picks the smallest result
Brotli wins 90% of the time — purpose-built for text, consistently 20-40% smaller than gzip
Compressed key-value store — store/retrieve gives agents persistent compressed storage at ~/.mcp-compress/
Shannon entropy analysis — analyze tells you if compression is even worth it before you do it
10/10 evals passing:
✓ Initialize returns protocol version
✓ Lists all 7 tools
✓ Compress returns valid base64 and ratio > 1x
✓ Round-trip is lossless
✓ Analyze returns compressibility recommendation
✓ Store and retrieve preserves data
✓ Stats returns valid counts
✓ List shows stored items
✓ Auto picks smallest algorithm
✓ Handles 100KB+ dataMIT
Analyze how compressible data is. Shows best algorithm, compression ratio, entropy, and recommendation. Use this before deciding whether to compress.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The data to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains the tool shows algorithms, ratios, and recommendations, implying a read-only operation without side effects. However, it does not explicitly state non-destructiveness or any other behavioral traits beyond the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences delivering purpose, output, and usage guidance. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description fairly covers what the tool does and when to use it. It even describes the output fields. A minor gap is lack of return format details, but that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'data' described in the schema as 'The data to analyze'. The description adds no additional meaning about the parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Analyze', 'Shows') and clearly identifies the resource ('compressible data'). It distinguishes from siblings like 'compress' and 'decompress' by focusing on analysis rather than action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this before deciding whether to compress.' This provides clear context, though it does not mention when not to use it or offer explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compress text/JSON/CSV data. Returns base64-encoded compressed data with compression ratio. Use algorithm="auto" to pick the best compression.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The data to compress (text, JSON, CSV, etc.) | |
| algorithm | No | Compression algorithm. Default: auto (picks best) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral context (return format, compression ratio) but fails to disclose error handling, size limits, or safety considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and key usage tip, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a compression tool with no output schema, it covers the return format and algorithm hint, but misses potential edge cases and input constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters. The description adds minimal extra value beyond reiterating the algorithm recommendation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (compress), the data types (text/JSON/CSV), and the output format (base64 with ratio), distinguishing it from sibling tools like decompress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a recommendation to use algorithm='auto', but no explicit guidance on when to use this tool vs alternatives or exclusions for small data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decompress previously compressed data. Requires the base64 compressed data and the algorithm used.
| Name | Required | Description | Default |
|---|---|---|---|
| compressed_base64 | Yes | Base64-encoded compressed data | |
| algorithm | Yes | Algorithm used for compression |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the operation (decompress) and input format, but does not describe the output, error handling, or behavior on incorrect algorithm.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 12 words, no fluff, essential information front-loaded. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple, but description omits output format. With no output schema, stating what the tool returns would improve completeness. Otherwise adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mirrors parameter names and types without adding new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('decompress') and resource ('previously compressed data'), with specific input requirements. It is distinct from sibling tools like 'compress' and 'analyze'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires 'base64 compressed data and the algorithm used', indicating prerequisites. While no direct alternatives are mentioned, the sibling context and clear purpose make usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decompress TurboQuant-compressed numerical data back to numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| compressed_data | Yes | The compressed_data string from a quantize result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description should disclose behavioral traits. It only describes the operation without mentioning safety, side effects, or errors. For a data transformation tool, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, front-loading the action and result. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate. However, it lacks details on return format or error handling, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the parameter at 100%, and the description adds meaningful context by specifying that the input comes from a quantize result, aiding the agent in understanding the expected source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it decompresses TurboQuant-compressed data back to numbers, specifying the action and resource. However, it could better differentiate from the sibling 'decompress' tool, which might cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'decompress'. It implicitly relates to 'quantize' but does not state that explicitly or provide contexts where it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all stored compressed items with their keys, sizes, and compression ratios.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It accurately describes a read-only list operation with no side effects. No contradictions, but it could mention if the tool requires specific permissions or has performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all necessary information without any extraneous content. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is complete. It clearly explains what the tool does and what information the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100% trivially). The description adds value by specifying the content of the list (keys, sizes, compression ratios), which is beyond the empty schema. Baseline for 0 parameters is 4, and this exceeds expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all stored compressed items, specifying the included information (keys, sizes, compression ratios). This distinguishes it from siblings like 'retrieve' (specific item) and 'stats' (aggregate statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for viewing all items but does not explicitly state when to use this tool versus alternatives like 'retrieve' or 'stats'. No exclusions or context are provided, leaving the agent to infer usage from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TurboQuant: Extreme compression for numerical data (prices, sensor readings, embeddings, vectors). Based on Google TurboQuant (ICLR 2026). Converts numbers to 1-4 bits using random rotation + quantization. Lossy but near-zero error on correlated data.
| Name | Required | Description | Default |
|---|---|---|---|
| numbers | Yes | JSON array of numbers, e.g., "[1.5, 2.3, 3.1]" or comma-separated "1.5,2.3,3.1" | |
| bits | No | Bits per value: 1, 2, 3, or 4. Lower = more compression, more error. Default: 4 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses algorithm ('random rotation + quantization'), lossiness, and correlation assumption. Could add details on side effects or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with name and algorithm, no extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, algorithm, and usage context. Lacks explanation of output format or return value, which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds no new parameter-specific information beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Extreme compression for numerical data' and specifies verb 'converts' with resource 'numbers'. Distinguishes from siblings by naming algorithm and compression type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use: 'prices, sensor readings, embeddings, vectors'. Notes lossy nature with 'near-zero error on correlated data'. Does not explicitly exclude scenarios or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve and decompress previously stored data by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The key used when storing the data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'decompress' as an action but lacks details on whether this is read-only, error handling (e.g., key not found), or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single 8-word sentence with zero wasted words. Front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with one parameter. Lacks details on return format or failure cases, but the core functionality is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with a clear description for the 'key' parameter. The description adds no additional semantic value beyond implying 'by key'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (retrieve and decompress) and the resource (data by key). Distinguishes from siblings like 'store' and 'decompress' which are separate operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when needing to retrieve previously stored data. The context is clear from the description and sibling names, though no explicit exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show compression statistics: total items stored, bytes saved, overall compression ratio.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It indicates a read-only operation showing statistics, which is appropriate. However, it lacks information on whether the stats are real-time, cached, or require prior compression operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that perfectly captures the tool's purpose and output. No wasted words; every element (show, compression statistics, and the three specific metrics) is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless stats tool with no output schema, the description is complete. It lists exactly what the tool returns, and there is no missing information needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, so no additional semantics are needed. The baseline for zero parameters is 4, and the description does not distract with unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Show compression statistics' and enumerates three specific metrics (total items stored, bytes saved, compression ratio). This verb+resource combination is unambiguous and distinct from siblings like 'list' or 'analyze'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear—use to retrieve compression stats. It doesn't explicitly list when not to use or contrast with siblings, but the simplicity of the tool makes alternatives obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compress data and store it to disk with a key. Retrieve later with the key. Like a compressed key-value store for agents.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data to compress and store | |
| name | No | Key name for retrieval. Auto-generated if not provided. | |
| algorithm | No | Compression algorithm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the core behavior (compress, store, retrieve) but omits details like overwrite behavior, auth requirements, or what happens if the key already exists. The auto-generation of 'name' is not mentioned, though schema covers it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The description is front-loaded with the main action and uses a concise analogy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema information; no mention of what the tool returns (e.g., key, success status). Error conditions or size limits are not covered. Adequate for a simple store but incomplete for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described. The description adds minimal value beyond the schema, not explaining parameter constraints like algorithm choice impact or data format limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compresses data and stores it to disk with a key, and that it can be retrieved later. It uses a relatable analogy (compressed key-value store) and distinguishes itself from siblings like 'compress' and 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for storing compressed data but does not explicitly state when to use this tool over alternatives like 'compress' or 'retrieve'. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0dequantizequantizev0.1.0analyzecompressdecompresslistretrievestatsstoreTools have distinct purposes (analysis, compression, storage), but compress and quantize could be confused by an agent without careful reading. Descriptions help clarify their different use cases.
All tool names are single-word imperative verbs (analyze, compress, quantize, etc.), following a consistent pattern without mixing conventions.
9 tools is an appropriate scope for a compression server, covering analysis, compression, storage, and statistics without being overwhelming.
Covers core compression workflows well, but lacks a 'delete' tool for stored items, which is a minor gap for managing the key-value store.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
61 text, security, converter, calculator, and PDF tools -- callable via MCP on one host.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ShipItAndPray/mcp-compress'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
