An MCP server that exposes slimtoken's token-optimization, budgeting, and preset-selection tools for LLM request bodies.
Optimize Anthropic/OpenAI/Ollama messages by minifying tools, system prompts, and message history; deduplicating tool results; distilling old turns; and pruning to a token cap.
Estimate token usage with the bundled offline cl100k_base tokenizer, including per-message breakdowns.
Prune RAG/conversation context from warm/cold memory into a ready-to-inject <cold_memory>/<recent_context> prompt block.
Lossily compress oversized tool results using type detection for directories, git output, logs, JSON, and source.
Inspect token budgets read-only, reporting headroom and whether the pair-safe pruner would drop leading messages.
Read the active slimtoken configuration derived from SLIMTOKEN_* environment variables.
List local model presets by VRAM tier and optionally measure live token reduction.
List high-context dense/MoE presets showing nominal context and effective raw-token capacity after compression.
Optimizes requests to Ollama's local API by reusing the OpenAI conversion to normalize to Anthropic's format, applying token minification, and converting back, reducing input tokens for local model inference.
Optimizes requests to the OpenAI API by converting bodies to Anthropic's canonical format, running the token-minification pipeline, and converting back, thereby reducing input tokens for OpenAI-compatible endpoints.
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., "@slimtoken Can you optimize this request to use fewer 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.
slimtoken is a standalone token-optimization and memory layer for LLM requests. It rewrites every request — tool schemas, system prompt, message history — before it leaves your machine: minifying, deduplicating tool results, distilling early turns, and pruning to a token budget. It runs on your own machine as an async proxy in front of any Anthropic, OpenAI, or Ollama-compatible backend, or as an MCP server, a CLI, or a plain Python library. Nothing is hosted; no network service beyond your chosen model backend is contacted.
git clone https://github.com/greyok00/slimtoken
cd slimtoken
./scripts/install.sh # pip install -e . + slimtoken install
slimtoken serve # proxy on port 8181; point your client at itDetails, including installing from a release wheel instead of a clone, are under Install.
Related MCP server: everything-slim
A client points at the slimtoken proxy instead of the model backend
(slimtoken install rewrites ANTHROPIC_BASE_URL).
Each request passes through the pipeline: tool-schema minify, system-prompt minify, message minify, dedup of byte-identical tool results, distill of old turns, and a token-budget backstop prune.
Code blocks are never touched. In the default code mode a tool result is
only replaced when it is byte-identical to a later copy — and the dropped
copy is stored, so slimtoken recall retrieves the exact original.
The request is forwarded to your backend and the response comes back essentially untouched; overhead is a few milliseconds.
Optionally, agent memory is served from ~/.slimtoken/memory: an
uncapped hot/warm/cold store with atomic writes and a distiller that folds
old material into short summaries.
Pipeline (slimtoken/pipeline) — one pass over each request that runs
the enabled stages in order and returns the rewritten body plus a stats
record; if nothing would change, it returns the original bytes untouched.
Stages — tool_minify deduplicates and trims tool JSON schemas;
system_minify shrinks the system prompt (fence-aware, so code inside stays
verbatim); message_minify cleans message bodies the same way;
dedup_tool_results stubs a tool result that is byte-identical to a later
one; distill_old_turns replaces distant prose with extractive summaries
(no model call); token_budget prunes to the configured ceiling; tool_result_compress and
dom_pruner compress oversized tool output and DOM text in the lossy
realtime mode.
Modes — code (default) never rewrites a tool result except an exact
duplicate; realtime additionally elides old turns and shortens the newest
tool result, for speech-to-speech conversation only. SLIMTOKEN_MODE
selects; SLIMTOKEN_MINIFY=0 disables everything.
Proxy (slimtoken/proxy) — an asyncio HTTP/1.1 forwarder that points at
SLIMTOKEN_UPSTREAM (default http://127.0.0.1:8080) and listens on port
8181; it keeps full-fidelity streaming and passes responses through without
rewriting model output.
Artifacts — every dropped byte is stored under a sha256 digest in
~/.local/state/slimtoken/artifacts; slimtoken recall <digest> prints the
exact original, so compression is reversible by construction.
Memory (slimtoken.memory) — a JSON/SQLite store at ~/.slimtoken/memory
with hot/warm/cold tiers, atomic appends, a scheduler, a loop guard, and
lifecycle hooks; writes are local files, nothing leaves the machine.
MCP servers — slimtoken-mcp (tools server, stdio) and
slimtoken-reframe-mcp (a CPU-only pass that turns a rambling prompt into a
tight instruction without an LLM round-trip), plus a memory MCP server over
the same store. Any MCP client that speaks stdio JSON-RPC can use them.
Built-in MCP tools exposed by slimtoken-mcp:
Tool | What it does |
| runs the full minify pipeline on a request body |
| counts tokens for a payload with the bundled cl100k tokenizer |
| cuts a message list to a token budget |
| shrinks one oversized tool result |
| reports how close a request is to the budget |
| prints the active mode and stage configuration |
| lists llama-server presets by GPU VRAM tier |
| lists dense/MoE presets sized for long context |
Memory MCP tools (same store, via the memory server): read, write,
search, clear per tier, plus stats (store sizes), integrity (per-tier
checksum validation), cold_list, workflow_run/workflow_status (ordered
task scripts under ~/.slimtoken/workflow), and cron_parse (cron
expression → ISO timestamps).
MCP support: any MCP-capable agent can connect to slimtoken-mcp and the
memory server directly. slimtoken lazy-mcp additionally fronts your other
MCP servers: it lists one generic stub tool per configured server (from
~/.slimtoken/lazy_mcp.json) so an agent never loads every server's full
schema set at startup, and calls through to the real server on demand. No
third-party MCP servers are installed by default — configure your own in
~/.slimtoken/lazy_mcp.json.
Example session: point Claude Code or any ANTHROPIC_BASE_URL client at the
proxy, then run an agent that reads files. Each request loses its duplicated
tool results and bloated schemas automatically; slimtoken recall <digest>
brings any dropped text back verbatim; the memory server keeps the agent's
notes on disk across runs. On an 8-turn session with heavy file reads, the
dedup pass alone removes ~73% of tokens when the same output is read twice
(see slimtoken modes --measure for the table run live on your machine).
Directory | Contents | Shipped as |
| pipeline, stages, proxy, CLI, MCP servers, memory | compiled |
|
| plain bash |
| unit + integration smoke suite | plain |
| bundled cl100k tokenizer vocab | plain data file |
Requirements: CPython 3.13 on Linux (x86_64), ~50 MB disk. The published wheel's compiled modules are Cython-built for that exact interpreter/platform combination — there is no source fallback, so other Python versions and platforms are not supported. No compiled backend is required at runtime — the proxy works against Anthropic/OpenAI/Ollama-compatible HTTP endpoints.
Default backend is whatever you point at (SLIMTOKEN_UPSTREAM, default
http://127.0.0.1:8080 — a local llama-server, or any Anthropic/OpenAI/Ollama
endpoint).
From a clone:
git clone https://github.com/greyok00/slimtoken
cd slimtoken
./scripts/install.sh # pip install -e . + slimtoken installFrom the release, without cloning:
gh release view -R greyok00/slimtoken --json assets -q '.assets[].name'
gh release download -R greyok00/slimtoken
pip install slimtoken-0.7.1-*.whl
slimtoken install # or: slimtoken serve --upstream http://127.0.0.1:8080Variable | What it controls |
|
|
|
|
| per-stage toggle ( |
| token-budget ceiling (default 131072) |
| newest turns kept verbatim by the distiller |
| enables tool-result compression (off in |
| backend URL (default |
| proxy listen port (default 8181) |
| opt-in HTTP/2 forwarding |
| path for minify stats JSON |
| where recalled originals are stored (default |
| TLS to the backend |
| memory store root (default |
| memory tier names, scheduler tick, distiller cadence, loop-guard state |
| path of the lazy-MCP server list (default |
slimtoken modes --measure # token-table run on your own tokenizer
slimtoken latency # one request through a running proxy, t0–t4 timing
python3 -m pytest tests/ # unit + integration suiteTool | Relationship to slimtoken |
Claude Code–type CLI agents | They run the loop and call the model directly; slimtoken sits in front of the model and shrinks what each call sends. |
Open Interpreter / OpenHands | They host the agent loop in-process; slimtoken is a network sidecar underneath any host, including these. |
aider | It manages git-integrated code edits; slimtoken edits nothing — it only makes the requests around such tools cheaper. |
LangChain-style frameworks | They shape requests at build time inside your app; slimtoken applies the same passes externally to every client, unmodified. |
pi.dev | An agent harness with its own token controls; slimtoken is a standalone layer that pairs with harnesses instead of replacing them. |
The closing pitch: if your workload already has an agent harness you like, slimtoken is the layer that drops its token bill without touching anything else.
MIT — see LICENSE.
Count tokens in a request body using the real cl100k_base tokenizer (bundled, offline). Returns total + per-message breakdown. The model arg is accepted for forward-compat but the count is cl100k-approximate for non-cl100k models.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | model name (informational only) | |
| tools | No | ||
| format | No | request format of the body (normalized to canonical before counting) | anthropic |
| system | No | ||
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavior: bundled/offline tokenizer, exact for cl100k, approximate for non-cl100k models. Without annotations, this carries the transparency burden; it also describes return shape (total + breakdown).
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?
Three sentences, front-loaded with the main function. Each sentence adds value—tokenizer type, return output, model parameter caveat.
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 the core operation, offline behavior, approximation caveat, and return structure. Lacks elaboration on the `tools`/`system` parameters, but the 'request body' phrasing implies they're included.
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 only documents model and format (40% coverage), and the description adds meaning for `model` (informational, approximate for non-cl100k). But it does not clarify `messages`, `tools`, `system`, or `format` usage beyond the schema's minimal description.
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?
Clear verb-object structure: 'Count tokens in a request body'. The addition of 'real cl100k_base tokenizer' and 'total + per-message breakdown' gives specific scope and differentiates from sibling tools like optimize or prune.
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 for counting tokens, but doesn't explicitly state when to prefer this over sibling tools like inspect_budget or optimize_messages. No exclusions or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the slimtoken config in use: the always-on MinifyConfig built from SLIMTOKEN_* env knobs (the single config surface shared by the proxy, CLI, and MCP server). Useful to see what slimtoken will do.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the config is 'always-on' and 'shared by the proxy, CLI, and MCP server,' indicating a persistent, global read-only resource. The word 'Return' implies no side effects, but it does not explicitly state that or describe error behavior, which is a minor gap.
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 two sentences, front-loaded with the primary action, and each clause adds value. It efficiently explains what the tool does, why it exists, and how it's configured without extraneous detail.
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 zero parameters and no output schema, the description provides enough context: it defines the returned object (MinifyConfig), its construction, and its shared role. This is complete for a simple config retrieval tool.
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 zero parameters, so the baseline is 4. The description adds context about the config's origin and scope, which is meaningful even though there are no parameters to document. It avoids redundancy with the empty 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 function: 'Return the slimtoken config in use' with a specific verb and resource. It further distinguishes the tool from siblings by specifying the config is built from SLIMTOKEN_* env knobs and shared across proxy, CLI, and MCP server, which is distinct from the optimization/estimation/pruning tools.
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 gives clear usage context: 'Useful to see what slimtoken will do.' This implies when an agent should call it, but it does not explicitly mention alternatives or when not to use it. Since the siblings are functionally distinct, the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
High-context VRAM-tier configs (dense AND MoE) showing how slimtoken compression expands the effective context window. Each row gives the largest nominal context that fits fully in VRAM (computed by config_optimizer, q4_0 KV, flash attn, full offload) and the effective raw-token capacity = nominal_ctx / (1 - reduction). Use best=true for just the largest-effective-context preset of a tier.
| Name | Required | Description | Default |
|---|---|---|---|
| best | No | return only the largest-effective-context preset for the tier | |
| vram_gb | No | filter to one tier (4/8/16) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it discloses the computation assumptions (config_optimizer, q4_0 KV, flash attn, full offload) and provides the formula for effective raw-token capacity. It also clarifies that rows represent presets and that best=true filters to the largest. Minor omissions include not stating default behavior when vram_gb is omitted.
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 four sentences, front-loaded with the primary purpose, then details the computation, the formula, and a useful parameter tip. Every sentence adds value and there is no redundancy or filler.
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 moderate complexity (VRAM tiers, compression, formulas), the description provides sufficient context for an agent to understand what the tool returns and how the values are computed. The lack of an output schema is partially mitigated by the description's mention of 'rows' and the formula. The main gap is not specifying the full return set when vram_gb is omitted.
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%, so the baseline is 3. The description adds no new parameter-specific syntax beyond the schema, but it does provide context for interpreting the output (formula for effective capacity). This is helpful but not essential, given the schema already explains both parameters clearly.
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 identifies the tool as providing high-context VRAM-tier configs for both dense and MoE models, with a specific scope of showing how compression expands context. It distinguishes itself from siblings like list_model_presets by focusing on VRAM tiers and effective context capacity. However, it lacks an explicit verb like 'list' or 'get', which slightly reduces clarity.
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 gives a specific usage hint for the 'best' parameter ('Use best=true...'), which is helpful. However, it does not explicitly state when to use this tool over alternatives like list_model_presets or get_config. The context is implied by the title and description, but no exclusions or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only token-budget inspection: counts system/tools/messages, reports headroom against a token_budget, and whether the pair-safe pruner would drop any leading messages. Does not modify the body.
| Name | Required | Description | Default |
|---|---|---|---|
| tools | No | ||
| format | No | request format of the body (normalized to canonical before inspection) | anthropic |
| system | No | ||
| messages | Yes | ||
| keep_last | No | ||
| token_budget | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description shoulders the full burden of behavioral disclosure. It explicitly states the tool is read-only, does not modify the body, and details what it counts and reports. This is solid transparency for an inspection tool, though it omits specifics like return format or error handling.
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 two sentences, front-loaded with 'Read-only token-budget inspection', and every phrase adds value. It avoids redundancy and clearly communicates the tool's core behavior without fluff.
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 annotations and output schema, the description covers the essential operational semantics: what it inspects, what it reports, and its side-effect-free nature. It does not elaborate on input format normalization or parameter details, but for a read-only inspection tool, the provided context is fairly complete.
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 has only 17% description coverage, so the description must compensate. It meaningfully explains the role of 'messages', 'system', 'tools', and 'token_budget' through the counting and headroom reporting, but it does not clarify 'format' (beyond schema enum) or 'keep_last', leaving gaps for those parameters.
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 function with a specific verb ('inspect') and resource ('token-budget'), and enumerates the exact outputs (counts, headroom, pruner decision). It distinguishes itself from sibling tools by emphasizing its read-only inspection nature, contrasting with the more action-oriented siblings like optimize_messages and prune_context.
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 context through 'Read-only' and 'Does not modify the body', signaling that this is for inspection, not modification. However, it does not explicitly name alternative tools or provide when-to-use vs. when-not-to-use guidance, so it stops short of the highest score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recommended local-model presets by GPU VRAM tier (4/8/16GB), each with a usable context. With measure=true, enriches each row with the live measured token reduction on a bloated payload (run by the pipeline itself).
| Name | Required | Description | Default |
|---|---|---|---|
| measure | No | run the pipeline to measure real reduction | |
| vram_gb | No | filter to one tier (4/8/16) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that 'List' is a read-only action and explains that measure=true triggers the pipeline to measure live token reduction, implying additional processing. It does not mention auth or rate limits, but for a listing tool this is reasonable context. The description adds valuable behavioral detail beyond the bare schema.
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 consists of two sentences that are tightly packed with relevant information. The main purpose is front-loaded, and the second sentence adds a conditional behavior. There is no fluff or redundancy; every phrase 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 listing tool with two optional parameters and no output schema, the description provides sufficient context: what the tool lists, the filtering criterion, and the optional enrichment behavior. It mentions that each preset 'has a usable context', giving a hint of the return content. It could be slightly more explicit about the exact response structure, but it does not leave a major gap.
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 meaning to the 'measure' parameter by explaining it 'enriches each row with the live measured token reduction on a bloated payload (run by the pipeline itself)', which is not in the schema. It also confirms the VRAM tiers (4/8/16GB) that align with the vram_gb parameter, providing useful context.
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 opens with 'List recommended local-model presets by GPU VRAM tier (4/8/16GB)', which is a specific verb+resource+scope statement. It clearly distinguishes this tool from sibling tools like optimize_messages, prune_context, and minify_tool_result, which are mutation/optimization tools, whereas this is a read-only listing operation.
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 clearly implies when to use this tool: when the user needs recommended local-model presets filtered by GPU VRAM tier. It also explains the optional measure=true behavior. However, it does not explicitly contrast with the sibling 'high_context_presets' tool or provide exclusions, so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compress a large tool_result content block using type detection (directory listing, git output, logs, JSON, source). LOSSY — emits a compact representation plus a [slimtoken-compressed] metadata header. Pair-safe by construction (only the content field changes).
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | tool_result content (string or list of text blocks) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and transparently discloses that the operation is LOSSY, emits a metadata header, and is pair-safe by construction (only the content field changes). This goes beyond a simple action verb and informs the agent about side effects and limitations.
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 two sentences, front-loaded with the main action, and every clause earns its place. It conveys purpose, behavioral traits, and safety in a compact form without repetition.
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 single parameter, no output schema, and no annotations, the description covers the core required context: it states what is compressed, how (type detection), the lossy nature, the output metadata marker, and the pair-safe guarantee. It does not specify exact output structure but sufficiently sets expectations 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 description coverage is 100%, so the parameter is already well-documented. The description adds minimal extra meaning beyond noting 'large' content and type detection, which does not change the parameter syntax or semantics.
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 starts with a specific verb 'Compress' and resource 'tool_result content block', and lists concrete type detection categories (directory listing, git output, logs, JSON, source). This clearly differentiates it from sibling tools like optimize_messages or estimate_tokens.
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 large tool_result content blocks but does not explicitly state when to use this tool over alternatives or when not to use it. There is no reference to sibling tools or exclusions, so it stays at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reduce prompt size while preserving message structure and tool-call validity (pair-safe, fence-aware). Returns the minified messages plus token counts. Lossy by default (distill + tool-result compression); disable stages via the SLIMTOKEN_MINIFY_* env knobs.
| Name | Required | Description | Default |
|---|---|---|---|
| tools | No | tool definitions to minify | |
| format | No | request format (anthropic=identity; openai/ollama are normalized to canonical, minified, then returned) | anthropic |
| system | No | system prompt (string or list of text blocks) | |
| messages | Yes | Anthropic-style messages array | |
| max_input_tokens | No | override the token_budget (hard prune cap) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states 'Lossy by default (distill + tool-result compression)' and mentions how to disable stages via SLIMTOKEN_MINIFY_* env knobs, which is meaningful for a mutation-like tool. It could go further by explaining 'distill' or authentication needs, but the disclosure is strong.
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 two concise sentences, front-loaded with the core purpose in the first sentence and key behavioral caveats in the second. Every word earns its place, with no filler or 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?
The description mentions the return value (minified messages plus token counts) and the lossy default with env-knob control, which is sufficient for a tool with a well-documented schema. However, it does not elaborate on what 'pair-safe, fence-aware' entails or how it differs from sibling tools, leaving minor gaps for deeper contextual 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% and each parameter already has a descriptive schema entry, including format behavior and default. The description adds no additional parameter-level detail beyond what the schema provides, so the baseline 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 a specific verb+resource: 'Reduce prompt size while preserving message structure and tool-call validity (pair-safe, fence-aware).' This clearly states the operation and its distinctive scope, distinguishing it from sibling tools like prune_context by emphasizing lossy compression and structural preservation.
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 clearly implies when to use the tool (for reducing prompt size while preserving structure) and gives config context via env knobs. However, it does not explicitly mention when not to use it or name alternatives among siblings, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RAG-style context pruning for a memory/conversation store: strip low-value text, retrieve warm entries relevant to a query, sliding-window summarize old turns, and enforce a token budget. Returns a ready-to-inject <cold_memory>/<recent_context> prompt block.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | current query for relevance retrieval | |
| cold_data | No | cold memory keyed by category (each value is a list of entries) | |
| max_tokens | No | ||
| warm_entries | Yes | warm/conversation entries (role+content dicts) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It outlines the internal algorithm (strip, retrieve, summarize, enforce) and the return type, but it does not disclose whether the operation is read-only, whether it modifies the underlying store, or any side effects such as data loss. This ambiguity prevents a higher score.
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 two sentences, front-loaded with the primary purpose, and includes only essential details. Every phrase contributes to understanding the tool's behavior and output, with no filler or repetition.
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?
The description explains the return value (a prompt block with cold_memory/recent_context), which is essential since there is no output schema. It also covers all key operations and the overall context of use. However, it does not specify the exact structure of cold_data beyond the schema, nor does it mention the required parameter warm_entries, though the schema handles that.
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 schema already describes 3 of 4 parameters (75% coverage), and the description adds marginal context by linking 'query' to relevance retrieval and 'warm entries' to sliding-window summarization. However, it does not add significant new meaning or format details beyond what the schema provides, especially for cold_data and max_tokens.
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 'prunes context' in a RAG-style manner, detailing specific operations: stripping low-value text, retrieving warm entries, summarizing old turns, and enforcing a token budget. This distinguishes it from sibling tools like optimize_messages or estimate_tokens, which focus on different aspects of token management.
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 context pruning in memory/conversation stores but does not explicitly state when to use this over alternatives. No comparisons are made to sibling tools like optimize_messages or minify_tool_result, so the guidance is implied rather than explicit.
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.
v0.3.3slimtoken.estimate_tokensslimtoken.get_configslimtoken.high_context_presetsslimtoken.inspect_budgetslimtoken.list_model_presetsslimtoken.minify_tool_resultslimtoken.optimize_messagesslimtoken.prune_contextScored across 8 tools
Several tools overlap in purpose: optimize_messages, prune_context, and minify_tool_result all reduce token counts, while list_model_presets and high_context_presets both list presets. However, descriptions clarify distinct use cases (full prompt vs. memory store vs. tool result; standard vs. high-context configs), so most boundaries are navigable.
Most tools follow a clear verb_noun pattern (optimize_messages, estimate_tokens, prune_context, minify_tool_result, inspect_budget, get_config, list_model_presets), but high_context_presets breaks the pattern as an adjective_noun phrase, causing a minor inconsistency.
With 8 tools, the set is well-scoped for a specialized token optimization server. Each tool addresses a distinct aspect (estimation, minification, pruning, budget inspection, config, presets) without unnecessary bloat or redundancy.
The tool surface covers the core lifecycle of token optimization: estimating, minifying, pruning, inspecting budgets, and retrieving config/presets. Minor gaps exist (e.g., no explicit tool to reverse or restore compressed content), but these are not essential given the lossy and config-driven design.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
LLM cost optimization gateway, repo token-waste auditor & model arbitrage MCP server.
LLM cost optimization gateway, repo token-waste auditor & model arbitrage MCP server.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows