sarup
Sarup is an MCP server that compresses text — especially Thai — to cut context tokens while keeping every original recoverable byte-for-byte.
Compress content with
sarup_compress, returning compressed text, a retrieval hash, and token-saving metrics; handles Thai prose, English, mixed Thai+code, JSON, and logs.Pick a mode:
extractive(default, offline TF-IDF, ~1 ms),semantic(embedding centrality, best ratio, needs Ollama),abstractive(local-LLM rewrite, slow),pipeline(cascade for maximum savings), orauto(semantic if Ollama is up, else extractive).Tune the trade-off with
target_ratio(0.3–0.7 keeping fraction) orlossless: truefor whitespace/JSON compaction only.Steer retention by passing
query; sentences relevant to it are scored higher and more likely kept.Recover originals exactly via
sarup_retrieve(hash)— every compress caches the original.Track savings cumulatively across the session with
sarup_stats.Optional automation: a PostToolUse hook compresses large Read/Bash/Grep outputs before they enter context.
Provides optional compression modes (semantic, abstractive, pipeline) using local LLM models hosted by Ollama for enhanced context reduction.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@sarupCompress this Thai paragraph to half its tokens."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
สรุป · Sarup
Thai-first context compression for Claude Code. An MCP server that actually shrinks Thai (50–78% fewer tokens) and caches every original so nothing is ever lost. Measured for what matters too: whether Claude still answers correctly.
สรุป means "to summarize." Headroom routes Thai through
noop(0% savings) because its whitespace tokenizer can't find Thai word boundaries. Sarup uses PyThaiNLP segmentation, so it compresses Thai as well as English — and caches every original so nothing is ever lost.
Contents
Related MCP server: cctx
Highlights
🇹🇭 Real Thai compression — PyThaiNLP
newmmword segmentation, not whitespace.♻️ Lossless by guarantee — every compress caches the original;
verified: trueproves a byte-for-byte round-trip.🎚️ Five modes: from offline 1 ms TF-IDF to a 78%-savings cascade.
🧠 Optional local LLM — embeddings + rewrite via Ollama, with automatic offline fallback.
📏 Honest metrics: a real tokenizer (tiktoken) at runtime; Claude's own tokenizer and a Thai QA eval for the published numbers (Does Claude still get it right?).
🕳️ Visible gaps:
[…]marks every place sentences were dropped, so Claude retrieves instead of mistaking a nearby fact for the answer.🔌 Content-aware — JSON compaction, log dedup, and verbatim code-fence preservation built in.
🛟 Can't break Claude — it's an MCP tool, not an API proxy; if the server is down the tools just go away and Claude keeps working.
Why it's safe — the two-tier guarantee
Tier | What | Guarantee |
Compressed view | the shrunk text the model works on | lossy · small · cheap |
Retrieval store | the original, keyed by a stable hash | lossless · recoverable |
Aggressive lossy compression is safe because the original is always one sarup_retrieve(hash)
away. This is how "maximum savings" and "100% accuracy" coexist — they live in different tiers.
How it works
Two entry points feed one engine: a cheap compressed view the model reads, and a lossless retrieval store that can restore the original byte-for-byte.
flowchart TD
M["🧑 Manual<br/>sarup_compress()"]:::entry --> R
A["⚙️ Automatic<br/>PostToolUse hook<br/>(Read · Bash · Grep)"]:::entry --> R
R{"Sarup compress<br/>extractive · semantic · abstractive · pipeline"}:::engine
R -- "compressed view<br/>50–78% fewer tokens" --> V["📄 Model context"]:::lossy
R -. "cache original" .-> S[("🗄️ Retrieval store<br/>hash → original")]:::lossless
V -. "need full detail?" .-> RET["🔑 sarup_retrieve(hash)"]:::lossless
RET --> S
S == "byte-for-byte ✓" ==> V
classDef entry fill:#e0e7ff,stroke:#6366f1,color:#111
classDef engine fill:#fde68a,stroke:#d97706,color:#111
classDef lossy fill:#fef3c7,stroke:#f59e0b,color:#111
classDef lossless fill:#bbf7d0,stroke:#16a34a,color:#111Manual — the model calls
sarup_compress/sarup_retrieveitself.Automatic — the hook intercepts large tool outputs, caches the original to
SARUP_DB_PATH, and substitutes the compressed view + a retrieval hash. Source code is skipped; small outputs pass through untouched.
Tools
Tool | Purpose |
| Compress; returns compressed text, hash, token metrics, |
| Recover the original content byte-for-byte. |
| Cumulative session savings. |
sarup_compress arguments
Arg | Type | Default | Meaning |
| string | — | Text to compress (required). |
| number |
| Fraction of prose to keep (0.1–0.9). |
| boolean |
| Only apply lossless transforms (whitespace / JSON compact). |
| string |
| What you need from the text; sentences matching it are kept. Pass it whenever you know: it took the QA eval from 69% to 100% at the same size. |
| string |
| See modes below. |
Compression modes
Mode | How | Needs Ollama | Savings¹ | Speed¹ | Output |
| TF-IDF scoring + fact boost + n-gram dedup | no | 52.7% | ~1 ms | verbatim subset |
| Embedding centrality + cosine dedup | yes | 63.8% | ~2 s | verbatim subset |
| Local-LLM rewrite | yes | 44.4% | ~8 s | paraphrased |
| Cascade: semantic → abstractive | yes | 78.2% | ~6 s | paraphrased |
| semantic if Ollama is up, else extractive | optional | 63.8% | ~2 s | subset |
¹ Measured on a 10-sentence Thai paragraph (522 tokens), rewrite model gemma4:12b. Every mode
stays 100% recoverable via the store; Ollama modes degrade gracefully to extractive when the
backend is down. (gemma4:e4b: pipeline 82.2%; June 2026, gemma3:12b: 88.1%.)
Extractive and semantic output is a verbatim subset of the input sentences, with […] on its
own line wherever sentences were dropped. Sentences carrying specifics (numbers, Thai digits,
identifiers like X-Api-Key) score higher than general statements, since those are what
questions ask about.
Measured results
$ .\.venv\Scripts\python.exe bench\benchmark.py
sample before after savings verify
Thai prose 522 247 52.7% OK
Thai prose (aggressive) 522 189 63.8% OK
English prose 105 60 42.9% OK
JSON (lossless) 67 44 34.3% OK
Logs 563 300 46.7% OK
TOTAL 1779 840 52.8% ALL OK → 100% recoverable
Mode comparison (Thai prose, 522 tok):
extractive 52.7% (1ms) · semantic 63.8% (2.1s) · auto 63.8% (2.1s)
abstractive 44.4% (8.3s) · pipeline 78.2% (5.8s) ← gemma4:12bToken counts via tiktoken cl100k_base. That is OpenAI's tokenizer and undercounts Claude,
most of all on Thai; bench\benchmark.py --claude adds a column from Claude's own tokenizer
(Anthropic count_tokens, needs an API key).
Does Claude still get it right?
Fewer tokens only help if the facts survive. bench\eval_qa.py compresses 8 Thai documents
(incident report, meeting notes, API docs, HR policy, product spec, support chat, README, sales
report; half line-per-sentence, half dense paragraphs) and asks Claude Opus 5.5 32 questions
from the compressed view alone, graded deterministically:
$ .\.venv\Scripts\python.exe bench\eval_qa.py # uses your local `claude` login
mode claude tok saved correct abstain wrong
──────────────────────────────────────────────────────────────
original 4601 0.0% 100% 0% 0
extractive:0.5 3204 30.4% 69% 31% 0
extractive:0.3 1969 57.2% 44% 56% 0
semantic:0.5 3214 30.1% 62% 38% 0
extractive:0.5+q 3207 30.3% 100% 0% 0
abstractive:0.5 2697 41.6% 91% 9% 0 ← gemma4:12b
pipeline:0.5 1854 59.8% 59% 41% 0 ← gemma4:12b(gemma4:e4b scored the same: abstractive 91%, pipeline 59%, wrong 0.)
wrong = 0 is the safety property: when a fact was dropped, Claude said so (abstain) and in real use would call
sarup_retrieve. It did not guess from what was left.abstain is the real cost of blind compression: about a third of specific questions need a retrieval round-trip at
0.5. Know what you're looking for? Pass it asquery(+qrow).abstractive keeps the most facts per token (91% at 42% saved) because a rewrite can keep every number while dropping words; extraction can only drop whole sentences. It costs seconds per document, so use it through
sarup_compress, not the hook.In both evals no paraphrase changed a fact into a wrong one, but 8 documents can't prove a rewrite never will, which is why the original stays one
sarup_retrieveaway.Token counts here are Claude's own (from the answer calls' usage) and include the ~40-token
[sarup: …]footer, which weighs heavily on these short (~570-token) documents and fades on the large outputs the hook actually compresses.8 documents is a small sample; differences of a couple of questions between modes are noise.
Before the fixes this eval drove (Oct 2026): dense Thai paragraphs were not compressed at all
(the sentence splitter's model wasn't installed), extractive:0.5 answered 59% with one
confident wrong answer, and semantic:0.5 47%.
Example
A real sarup_compress call on a Thai paragraph (mode="auto", Ollama up → semantic):
// → sarup_compress(content="…518-token Thai paragraph…", mode="auto")
{
"compressed": "จุดเด่นที่สำคัญที่สุดคือมันไม่มีทางทำให้ Claude พัง…",
"hash": "caa568140bec0ff734937cf5",
"original_tokens": 518,
"compressed_tokens": 154,
"tokens_saved": 364,
"savings_percent": 70.3,
"transforms": ["semantic_extractive", "embeddings", "thai"],
"lossy": true,
"verified": true, // round-trip proven byte-for-byte
"token_method": "tiktoken:cl100k_base"
}The model keeps working on the 154-token view; the full 518-token original is one call away:
// → sarup_retrieve(hash="caa568140bec0ff734937cf5")
{ "content": "…the exact original text, restored byte-for-byte…" }Install
As a Claude Code plugin (easiest)
Needs uv: the plugin runs Sarup through uvx, which fetches
Python and the dependencies on first use. Nothing to clone. In Claude Code:
/plugin marketplace add PHUICMT/sarup
/plugin install sarup@sarupThat installs the MCP server, the auto-compression hook and the /sarup:sarup-setup skill.
The cache lives in the plugin's data directory, so it survives plugin updates. The first start
takes a few seconds while uvx builds the environment. From a shell instead:
claude plugin marketplace add PHUICMT/sarup, then claude plugin install sarup@sarup.
Ollama is optional. Without it everything works offline: the hook and the default
extractive mode never touch it, and asking for semantic, abstractive or pipeline
falls back to extractive with a setup field that names what to install. sarup_stats
shows what is available, and /sarup:sarup-setup walks through adding
Ollama and the models below.
From PyPI (any MCP client)
The package is sarup on PyPI. With uv, nothing to install
by hand; point any MCP client at uvx sarup:
{
"mcpServers": {
"sarup": {
"command": "uvx",
"args": ["sarup"],
"env": { "SARUP_DB_PATH": "/home/me/.sarup-cache.db" }
}
}
}In Claude Code without the plugin: claude mcp add sarup -s user -- uvx sarup. The hook is
uvx --from sarup sarup-hook --db <same file as SARUP_DB_PATH>. pip install sarup works
too and puts sarup and sarup-hook on PATH.
From a clone
One command (creates the venv, installs everything, registers the MCP server for all projects, idempotent):
.\scripts\setup.ps1 -All # Windows (-All also adds the hook, the /sarup-setup skill, pulls Ollama models)
./scripts/setup.sh --all # Linux / WSL / macOSTip:
-All/--allinstalls a global/sarup-setupskill, so on any other machine you can just type/sarup-setupin Claude Code and it walks through the install. (Or runscripts/install-skill.ps1/install-skill.shon its own.)
Uninstall just as cleanly (only removes what Sarup added; -Purge/--purge also
deletes the venv + cache):
.\scripts\uninstall.ps1 # Windows
./scripts/uninstall.sh # Linux / WSL / macOSpy -3.11 -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev]"Optional local-LLM modes (semantic / abstractive / pipeline) need Ollama:
ollama pull nomic-embed-text # embeddings → semantic mode
ollama pull gemma4:12b # rewrite → abstractive / pipeline, 7.6 GB (or gemma4:e4b / gemma3:12b)Register with Claude Code
One-command setup (recommended). Detects this machine's paths, probes Ollama
(picks the best mode + models), and merges into .mcp.json / .claude/settings.json
without clobbering anything already there (a .bak is written first):
.\.venv\Scripts\python.exe scripts\install.py --with-hook --pullNo Ollama? It configures offline
extractivemode — still fully works.Ollama up? It auto-selects
nomic-embed-text(semantic) + the best installed rewrite model (gemma4:12b→gemma4:e4b→gemma3:12b→qwen3) forsarup_compress. The hook staysextractiveeither way (it runs on every tool call).--pullfetches any missing models.Idempotent — safe to re-run;
--globalwrites to~/.claudeinstead.
Manual — or add it yourself to your MCP config (e.g. .mcp.json or ~/.claude.json).
Replace <SARUP_DIR> with the absolute path where you cloned this repo (the installer
above fills these in for you):
{
"mcpServers": {
"sarup": {
"command": "<SARUP_DIR>/.venv/Scripts/python.exe",
"args": ["-m", "sarup.server"],
"env": { "SARUP_DB_PATH": "<SARUP_DIR>/.sarup-cache.db" }
}
}
}On Linux/macOS the interpreter is
<SARUP_DIR>/.venv/bin/python.
Or run it directly over stdio:
.\.venv\Scripts\python.exe -m sarup.serverAuto-compression hook
Skip manual tool calls entirely: install the PostToolUse hook and large Read/Bash/Grep
outputs are compressed before they enter context, with the original cached for retrieval.
Source-code reads are skipped for safety. Full setup in hooks/README.md.
Fixed in October 2026. Earlier versions returned the compressed text as a plain string. Claude Code only accepts
updatedToolOutputin the tool's own shape ({stdout, stderr, …}for Bash,{type, file: {content, …}}for Read) and silently dropped the string, so the hook never applied on any surface. It now keeps each tool's shape; verified on the CLI (2.1.289): the model receives the compressed view and the retrieval hash. To see what the hook does on your build, setSARUP_HOOK_LOGto a file path (one JSON line per call).
The plugin wires this up for you. From a clone, replace <SARUP_DIR> with your clone path, or
run install.py --with-hook:
{
"hooks": {
"PostToolUse": [
{ "matcher": "Read|Bash|Grep",
"hooks": [{ "type": "command",
"command": "<SARUP_DIR>/.venv/Scripts/sarup-hook --db <SARUP_DIR>/.sarup-cache.db" }] }
]
}
}Privacy & data
To guarantee recovery, Sarup caches the original content in the store. Two things to know:
With
SARUP_DB_PATHset, originals are written to that SQLite file in plaintext (no encryption). Treat it like a cache of whatever you compressed.If you compress tool outputs that contain secrets (e.g. a
.envdump or credentials in a log), those land in the cache too. The auto-hook skips source-code/config file reads, butBashoutput is fair game — review what you point it at.
*.db is git-ignored, so the cache never gets committed. For zero on-disk
footprint, leave SARUP_DB_PATH unset (memory-only; the MCP server then loses
the cache on restart, and the hook will not substitute — see the hook docs).
Configuration
Var | Default | Meaning |
| (in-memory) | SQLite path for a persistent, cross-process store.Required for hook retrieval. |
|
| Ollama endpoint. |
| best installed | Model for abstractive / pipeline rewrite. Unset: first installed of |
|
| Model for semantic embeddings. |
|
| Hook compression mode. |
|
| Hook only compresses outputs with at least this many tokens (token-based, fair across languages). |
| (off) | File to append one JSON line per hook call (event, tool, size, substituted). |
Project structure
sarup/
├── src/sarup/
│ ├── server.py # MCP stdio server — 3 tools
│ ├── compressor.py # router + modes (extractive/semantic/abstractive/pipeline/auto)
│ ├── thai.py # PyThaiNLP tokenization, sentence split, TF-IDF
│ ├── semantic.py # embedding centrality + cosine dedup
│ ├── llm.py # optional Ollama backend (generate + embed)
│ ├── tokens.py # real token counting (tiktoken)
│ └── store.py # CCR store: hash → original (memory + SQLite)
├── hooks/
│ ├── sarup_hook.py # PostToolUse auto-compression hook
│ └── README.md # hook install guide
├── bench/benchmark.py # before/after measurement
├── tests/ # test_thai, test_mcp, test_hook, ...
├── README.md
└── STACK.md # full stack + techniquesTech stack & techniques
Python 3.11 · MCP · PyThaiNLP newmm · tiktoken · Ollama (optional) · SQLite · hatchling · pytest.
The technique behind each mode — TF-IDF scoring, embedding centrality, cascade pipeline, content routing, and graceful degradation — is documented in STACK.md.
Testing
.\.venv\Scripts\python.exe -m pytest tests/ -qThe suite covers Thai NLP, the MCP tool contracts, every mode (including Ollama-fallback paths), the roundtrip-verify guarantee, and the auto-compression hook (incl. cross-process retrieval).
Quality is measured separately, since it needs a model: bench\eval_qa.py (see
Does Claude still get it right?). It runs on the local
claude CLI by default, or --backend api with an Anthropic API key; --dry-run and
--limit keep a check cheap; a full run is ~170 Claude calls.
Releasing
Bump
versioninpyproject.tomlandserver.json(both places in it).Push a matching tag:
git tag v0.2.0 && git push origin v0.2.0. Thepublishworkflow tests, builds and uploads to PyPI through trusted publishing (no token).List the release in the MCP registry:
mcp-publisher login github, thenmcp-publisher publish(readsserver.json; themcp-namecomment at the top of this README proves the PyPI package belongs to it).
The plugin needs none of this: it installs from the repo and updates with each commit.
Roadmap
Grow the QA eval past 8 documents (long tool outputs, logs, mixed code) before changing defaults such as
auto→ semantic on the strength of it.Move to
mcp2.x (pinned<2for now: 2.x droppedServer.list_tools).Optional Typhoon 2.1 abstractive (blocked on an Ollama template fix).
Per-content adaptive
target_ratio.Published PyPI package (
sarup) and MCP registry listing (io.github.PHUICMT/sarup).Installable as a Claude Code plugin.
License
MIT
Available Tools
3 toolssarup_compressA
Compress content for context efficiency. Supports Thai prose, English prose, mixed Thai+code, JSON, and logs. Returns compressed text, a retrieval hash, and token-saving metrics. Use sarup_retrieve(hash=...) to recover the original when needed.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Prose strategy. 'extractive' (default): offline TF-IDF, verbatim subset, ~1ms. 'semantic': embedding centrality, best ratio (needs Ollama). 'abstractive': local-LLM rewrite (needs Ollama, slow). 'pipeline': cascade semantic -> abstractive for maximum savings. 'auto': semantic if Ollama is up, else extractive. All modes stay 100% recoverable via sarup_retrieve. | extractive |
| query | No | Optional context query. Sentences relevant to this query are scored higher and more likely to be kept. | |
| content | Yes | Content to compress | |
| lossless | No | Only apply lossless transforms (whitespace/JSON compact). Default false. | |
| target_ratio | No | Fraction of prose to keep (0.3–0.7). Default 0.5. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return values and the recoverability of the original through sarup_retrieve. It does not mention side effects or performance, but the schema covers behavioral details for the modes. The description provides sufficient transparency for safe usage.
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 highly concise: two sentences that front-load the primary verb and resource, list supported types, mention return values, and reference the sibling tool. Every sentence serves a clear purpose without 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 absence of an output schema, the description correctly mentions the return values (compressed text, retrieval hash, metrics). The input schema is comprehensive, so the description does not need to repeat parameter details. However, it could briefly note that mode selection is covered by the schema. Overall, it is mostly complete for an agent to understand the tool's role and output.
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 the baseline is 3. The description adds general context (supported content types, recoverability) but does not elaborate on specific parameters like 'mode' or 'target_ratio'. Since the schema already thoroughly describes each parameter, the description adds minimal extra value beyond stating the overall purpose.
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 purpose: 'Compress content for context efficiency.' It specifies supported content types (Thai prose, English prose, mixed Thai+code, JSON, logs) and mentions the return values (compressed text, retrieval hash, token-saving metrics). It also distinguishes itself from its sibling by referencing sarup_retrieve for recovery.
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 indicates when to use the tool (compression for context efficiency) and how to recover the original using sarup_retrieve. However, it does not explicitly state when not to use it or provide alternative tools beyond recovery. Given the context of siblings (sarup_retrieve, sarup_stats), the usage context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sarup_retrieveA
Retrieve the original uncompressed content by hash. The hash is returned by sarup_compress.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | 24-char hash returned by sarup_compress |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description indicates a read-only operation ('retrieve'), but lacks disclosure of error behavior, authentication needs, or what happens on invalid hash. Non-destructive nature is implied.
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?
One sentence, front-loaded with action and resource. No extraneous words. Every part 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 simple retrieval tool with one parameter and no output schema, the description adequately explains input source and action. Lacks details on response format but sufficient for basic 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?
The single 'hash' parameter is documented in the schema with type and format. The description confirms its origin ('returned by sarup_compress') but adds no new semantic details beyond 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 action ('retrieve') and the resource ('original uncompressed content'), and distinguishes it from sibling tools (sarup_compress and sarup_stats) by referencing the hash source.
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 ('by hash returned by sarup_compress'), providing clear context. It does not explicitly exclude other use cases but the intent is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sarup_statsA
Return cumulative compression statistics for this session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states it returns 'cumulative compression statistics' but does not specify what statistics, the data format, or whether it has side effects. Given the lack of annotations, more details are 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, concise sentence that is front-loaded with the action and key information. No unnecessary 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?
Given the tool has no parameters and no output schema, the description provides the basic purpose but lacks details about what statistics are included or how they are presented. It is adequate but not comprehensive.
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 tool has no parameters, and the schema coverage is 100% trivially. The description does not need to add parameter information. Baseline score of 4 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?
The description clearly states the tool returns 'cumulative compression statistics for this session', which is a specific action with a clear resource. The sibling tools 'sarup_compress' and 'sarup_retrieve' indicate different operations, so this tool is well-differentiated.
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 the tool is for retrieving statistics about a compression session, but it does not explicitly state when to use it versus alternatives or any prerequisites. No guidelines on exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
sarup_compress - First observed
sarup_retrieve - First observed
sarup_stats
TDQS
Scored across 3 tools
Each tool has a distinct, well-defined purpose: compressing, retrieving via hash, and reporting statistics. There is no overlap or ambiguity.
All tool names follow a consistent pattern with the 'sarup_' prefix followed by a verb (compress, retrieve, stats), making them predictable and easy to distinguish.
Three tools is appropriate for the focused domain of context compression and retrieval. Each tool serves a clear, necessary function without bloat or shortage.
The tool set provides complete lifecycle coverage: compress, retrieve, and monitor statistics. No obvious gaps for its stated purpose.
Maintenance
Related MCP Connectors
Compress coding-agent context ~64%. Hosted Neural Keep MCP for Cursor/Claude/Codex.
Compress prose for LLM context windows. Per-call USDC billing, signed receipt.
A paid remote MCP for OpenAI Codex context compressor, built to return verdicts, receipts, usage log
Free no-LLM token savers: URL→Markdown, outline, JSON trim, log compress, token count; x402 extras
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables context compression for Claude Code by offloading large file queries and document processing to Ollama, saving context window tokens.27 PyPIMIT
- AlicenseNot gradedqualityCmaintenanceEnables Claude Code to reduce token usage by 70-90% using a local LLM for codebase indexing, tool output compression, and turn summarization.40 npm3MIT
- AlicenseNot gradedqualityDmaintenanceAutomatically reduces token usage in Claude Code sessions using algorithmic optimizations like code compression, smart file reading, output summarization, and prompt rewriting, with no extra API calls or cost.41 npm1MIT
- AlicenseNot gradedqualityDmaintenanceToken compression for AI contexts, reducing token consumption by compressing conversation exchanges before they enter the LLM context window.MIT