logslim-mcp
This server provides a compact_output tool to process noisy command output (test/build/lint logs) before an AI agent reads it, dramatically reducing token consumption.
What you can do:
Strip ANSI colors and spinner/progress-bar garbage from raw stdout/stderr
Deduplicate repeated/spammy lines (e.g., 120 identical deprecation warnings collapsed into one)
Collapse
node_modulesstack frames to reduce noise from vendor internalsExtract structured errors with file name, line number, message, and kind
Attach fix cards (~30 tokens each) for known error codes (e.g.,
TS2339,ECONNREFUSED,ERESOLVE) with actionable hintsControl compaction mode:
failure(compact hard only on non-zero exit, default),full(always compact hard), orlight(strip ANSI only)Enforce a token budget to hard-cap output size while preserving errors and head/tail context
Pass the exit code so the tool adjusts compaction behavior based on success or failure
Receive structured results including compacted text, extracted error list, fix cards, and savings stats (tokens in/out, % saved)
Typical savings range from 64–92% fewer tokens compared to reading raw logs directly.
Posts structured failure summaries on pull requests when CI fails, including file, line, fix hints, and token reduction stats.
logslim
CI failed? Get a 5-line PR summary — not a 400-line Actions log.
Agent reading test output? Cut 80–95% of the tokens.
When tests or builds fail, you scroll GitHub Actions logs. When Claude Code or Cursor runs
npm test, the agent reads everything — progress bars, 120 identical warnings, 40 frames
of node_modules. logslim fixes both:
CI / humans — GitHub Action posts structured failures on your PR (file, line, fix hints)
Agents / tokens — CLI + MCP compacts noisy output before an LLM reads it (~80–95% savings on failures)
npx logslim -- npm testNo account. No API key. MIT open source.
GitHub Action — PR failure summary
When CI fails, post a readable summary on the pull request instead of making reviewers dig through Actions logs.
permissions:
contents: read
pull-requests: write
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- name: Run tests
id: test
run: npm test 2>&1 | tee test-output.log
continue-on-error: true
- name: Post failure summary
if: steps.test.outcome == 'failure' && github.event_name == 'pull_request'
uses: P156HAM/logslim/action@v0.4.0
with:
log-file: test-output.log
exit-code: 1
github-token: ${{ secrets.GITHUB_TOKEN }}
- name: Fail job
if: steps.test.outcome == 'failure'
run: exit 1What gets posted on the PR:
Structured failures with
file:lineand messagesFix hints for known codes (
TS2339,ERESOLVE, …)Link to the full CI log
Token/log reduction stats (useful when agents also read the output)
The Action uses the same engine as the CLI — compaction, error extraction, and code cards. You get human-readable PR comments and agent-ready JSON from one tool.
Input | Default | Purpose |
| (required) | Path to captured test/build log |
|
| Exit code of the failed command |
| (required) |
|
|
| npm version to run |
|
| Don't comment when no failure detected |
Related MCP server: token-filter-mcp
See it work (30 seconds)
git clone https://github.com/P156HAM/logslim.git
cd logslim && npm install && npm run build && npm run demoOr without cloning:
npx logslim -- node -e "console.log('ok'); for(let i=0;i<30;i++)console.log('warn '+i); throw Error('fail')"Before → After
BEFORE — what the agent reads today (~18 lines here; real runs are 500–3000):
PASS src/utils.test.ts
console.warn deprecated prop id=1000
console.warn deprecated prop id=1001
console.warn deprecated prop id=1002
... (same warning ×120)
FAIL src/checkout/cart.test.ts
Expected: 89.10
Received: 99.00
at cart.test.ts:48:27
at node_modules/jest-circus/build/utils.js:298:28
at node_modules/jest-circus/build/utils.js:231:10
at node_modules/jest-circus/build/run.js:252:3
... (15 more node_modules frames)
Test Suites: 1 failed, 1 passed, 2 totalAFTER — what logslim gives the agent:
PASS src/utils.test.ts
console.warn deprecated prop id=1000
console.warn deprecated prop id=1001
console.warn deprecated prop id=1002
(+5 similar lines omitted by logslim)
FAIL src/checkout/cart.test.ts
Expected: 89.10
Received: 99.00
at cart.test.ts:48:27
at node_modules/jest-circus/build/utils.js:298:28
… 3 vendor/internal frames collapsed by logslim
Test Suites: 1 failed, 1 passed, 2 totalSame failure. Same fix. ~92% fewer tokens.
How it works
npm test ──► logslim ──► agent / CI / you
│
├─ 1. Strip ANSI colors & spinner garbage
├─ 2. Dedupe repeated lines (warn spam)
├─ 3. Collapse node_modules stack frames
├─ 4. Group similar lines (timestamps/ids masked)
├─ 5. Extract structured errors (file, line, message)
├─ 6. Attach fix cards for known codes (TS2339, ERESOLVE…)
└─ 7. Optional token budget (trim middle, keep errors)Failure mode (default): tests pass → light cleanup only. Tests fail → full pipeline. You only pay the compaction cost when something actually broke.
Every removed section is marked in place ((+47 similar lines omitted by logslim))
so the agent knows data was elided and can re-run the raw command if needed.
Install
npm install -g logslim
# or zero-install:
npx logslim -- npm testRequires Node 18+.
Usage
Basic — wrap any command
logslim -- npm test
logslim -- python -m pytest -x
logslim -- npx tsc --noEmitExit code is preserved. Output on stdout is compacted. Stats on stderr.
Pipe mode
npm test 2>&1 | logslim
npm test; logslim --exit-code $? 2>&1 < full.log # if you saved outputJSON — for agents and CI
logslim --json -- npm test{
"exitCode": 1,
"failed": true,
"compacted": "FAIL src/checkout/cart.test.ts\n...",
"errors": [
{
"file": "cart.test.ts",
"line": 48,
"message": "Expected: 89.10, Received: 99.00",
"kind": "assertion"
}
],
"codes": [
{
"id": "TS2339",
"lang": "typescript",
"meaning": "Property does not exist on type",
"fix_steps": [
"Check for typos",
"Extend the interface",
"Use optional chaining"
]
}
],
"stats": {
"tokensIn": 3296,
"tokensOut": 252,
"saved": 0.92,
"applied": "full"
}
}The agent reads compacted + errors + codes — not thousands of lines of prose.
CI context (GitHub Actions)
logslim --json --attach git,ci -- npm testPrepends: branch: feat/x | commit: a3f2c1d | pr: #42 (from GITHUB_* env vars).
All options
Flag | What it does |
| Compact hard only on failure (default) |
| Always compact hard |
| Strip ANSI only, never aggressive dedupe |
| Structured output (see above) |
| Prepend branch/commit/CI metadata |
| Hard token cap; errors + head/tail survive |
| For pipe mode when you know the exit code |
| Skip error code fix cards |
| Hide stderr savings footer |
MCP server (Claude Code / Cursor)
Lets the agent call compaction as a tool — no manual piping.
Project .mcp.json or Claude Desktop config:
{
"mcpServers": {
"logslim": {
"command": "npx",
"args": ["-y", "logslim-mcp"]
}
}
}Tool: compact_output — pass output (raw log text) and optional exit_code.
Returns compacted text, extracted errors, fix cards, and stats.
Local dev:
npm run build && npm run mcpTell your agent to use it
Add to CLAUDE.md, AGENTS.md, or .cursor/rules:
When running tests, builds, or linters that produce verbose output:
- Prefer: `logslim --mode failure --json -- <command>`
- Read the `compacted`, `errors`, and `codes` fields before debugging.
- If output was elided, re-run the raw command only if you need full logs.Error code fix cards
When logs contain known codes, logslim attaches a short fix card (~30 tokens) instead of making the agent guess or search docs.
Family | Examples | Source |
TypeScript | TS2339, TS2554, TS2307 |
|
Node | ECONNREFUSED, ENOTFOUND |
|
npm | ERESOLVE, ELIFECYCLE |
|
Hand-curated pocket references — not scraped docs. PRs welcome to add codes.
Measured savings
Log type | Lines | Tokens | Saved |
Jest (warn spam + 1 failure) | 149 → 25 | ~3,300 → ~250 | 92% |
Webpack build (asset noise + 2 TS errors) | 548 → 55 | ~8,900 → ~1,000 | 88% |
Pytest (25 identical failures) | 356 → 153 | ~4,300 → ~1,500 | 64% |
Token counts are estimated (~4 chars/token). Good for relative savings, not billing.
Library API
import { compact, process } from "logslim";
const { text, stats } = compact(rawLog, { mode: "failure", exitCode: 1 });
const result = process(rawLog, {
mode: "failure",
exitCode: 1,
attach: ["git", "ci"],
});
// result.text, result.errors, result.codes, result.statsWhen to use logslim
Use it | Skip it |
CI failed and you want a PR summary, not a 400-line log | Tests passed and output is already short |
AI agents running tests/builds locally or in CI | You already tee full logs to disk for audit |
Long repetitive failure output (jest, pytest, webpack) | Platform already truncates well enough for you |
MCP workflows where tool output hits context limits | You need full logs for compliance archive |
Keep full logs if you need them:
npm test 2>&1 | tee full.log | logslimDevelopment
npm install
npm test
npm run build
npm run demoContributing
logslim gets sharper every time it learns a new error code or a new log format — and both are easy first contributions:
Add an error fix card (TypeScript / Node / npm) — a ~5-minute, pure-JSON PR.
Share a log that compacts badly — paste real output from a tool logslim mangles.
Add support for a new runner — Playwright, pytest, vitest, cargo, gradle…
Start here: good first issues · CONTRIBUTING.md
License
MIT — use freely, no account required.
Available Tools
1 toolcompact_outputA
Compact noisy command output before reading it. Strips ANSI, dedupes spam, collapses stack traces, extracts errors, and attaches short fix cards for known error codes (TS####, ECONNREFUSED, npm ERESOLVE). Use when test/build/lint output is long.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | failure = compact hard only on failure (default) | |
| budget | No | Max output tokens after compaction | |
| output | Yes | Raw stdout+stderr from a command | |
| exit_code | No | Command exit code if known (0 = success) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It details the transformations performed (stripping, deduplication, collapsing) and mentions the attachment of fix cards for known error codes. This is comprehensive, though it does not discuss potential side effects like data loss or truncation thresholds.
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, consisting of two sentences that convey the core functionality and usage context. Every word adds value, and the structure is front-loaded with the key verb and resource.
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 no annotations and no output schema, the description adequately explains what the tool does and when to use it. It covers the main transformations and error code handling. It could mention the return format (e.g., compacted string) but is otherwise complete for its purpose.
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 covers 100% of parameters, so the baseline is 3. The description does not add specific parameter-level meaning beyond what the schema provides; it focuses on overall behavior. It does not elaborate on how 'mode' or 'budget' affect the output, which would be helpful.
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: compacting noisy command output by stripping ANSI, deduplicating spam, collapsing stack traces, extracting errors, and attaching fix cards. It specifies the target resource (command output) and the action (compact), making it distinct and unambiguous.
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 says 'Use when test/build/lint output is long,' providing a clear context for use. While no alternatives are mentioned due to lack of siblings, it gives sufficient guidance for when to invoke this tool.
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. Dates show when Glama detected each change.
1 tool update
v0.1.0- First observed
compact_output
TDQS
With only one tool, there is no possibility of confusion between tools. The purpose is clearly defined.
The single tool uses a clear snake_case name consistent with itself. No pattern inconsistency exists.
A single tool is on the lower end of the typical range. While it serves a narrow, well-defined purpose, it feels thin for a server, but not an extreme mismatch.
For its stated domain of compacting noisy command output, the tool covers the essential functionality. No obvious gaps for its intended use.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Deterministic AI agent microtools, no accounts/API keys. fetch_extract: 98% token cut. 38 tools.
A paid remote MCP for OpenAI Codex context compressor, built to return verdicts, receipts, usage log
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
471SaaS intelligence for AI agents. 5 unified tools cover 1,000+ services with 91-96% token savings.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceFilters verbose terminal output from commands like npm install, pip install, docker build, and pytest, reducing context token consumption for AI agents by condensing logs, removing progress bars, and grouping repeated warnings.-
- AlicenseAqualityAmaintenanceAn MCP server that intelligently filters and compresses tool outputs to reduce context window usage, saving up to 90% of tokens by removing noise such as passing tests and redundant information.5359MIT
- AlicenseNot gradedqualityCmaintenanceCompresses, deduplicates, and filters tool outputs to optimize token usage and context window for AI agents.MIT

Log Reducerofficial
AlicenseNot gradedqualityDmaintenanceReduces log files to remove noise and duplicate information, cutting tokens by 70-90% for AI agents, preserving only errors, warnings, and unique events.52MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/P156HAM/logslim'
If you have feedback or need assistance with the MCP directory API, please join our Discord server