Skip to main content
Glama

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.

npm license node logslim MCP server

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:

  1. CI / humans — GitHub Action posts structured failures on your PR (file, line, fix hints)

  2. Agents / tokens — CLI + MCP compacts noisy output before an LLM reads it (~80–95% savings on failures)

npx logslim -- npm test

No 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 1

What gets posted on the PR:

  • Structured failures with file:line and messages

  • Fix 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

log-file

(required)

Path to captured test/build log

exit-code

1

Exit code of the failed command

github-token

(required)

secrets.GITHUB_TOKEN with pull-requests: write

logslim-version

0.3.0

npm version to run

skip-on-success

true

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 demo

Or 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 total

AFTER — 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 total

Same 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 test

Requires Node 18+.


Usage

Basic — wrap any command

logslim -- npm test
logslim -- python -m pytest -x
logslim -- npx tsc --noEmit

Exit 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 output

JSON — 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 test

Prepends: branch: feat/x | commit: a3f2c1d | pr: #42 (from GITHUB_* env vars).

All options

Flag

What it does

--mode failure

Compact hard only on failure (default)

--mode full

Always compact hard

--mode light

Strip ANSI only, never aggressive dedupe

--json

Structured output (see above)

--attach git,ci

Prepend branch/commit/CI metadata

--budget 2000

Hard token cap; errors + head/tail survive

--exit-code N

For pipe mode when you know the exit code

--no-codes

Skip error code fix cards

--no-stats

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 mcp

Tell 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

errors/typescript.json

Node

ECONNREFUSED, ENOTFOUND

errors/node.json

npm

ERESOLVE, ELIFECYCLE

errors/npm.json

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.stats

When 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 | logslim

Development

npm install
npm test
npm run build
npm run demo

Contributing

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 tool
compact_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNofailure = compact hard only on failure (default)
budgetNoMax output tokens after compaction
outputYesRaw stdout+stderr from a command
exit_codeNoCommand exit code if known (0 = success)

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev0.1.0
    • First observedcompact_output

TDQS

A4.3/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion between tools. The purpose is clearly defined.

Naming Consistency5/5

The single tool uses a clear snake_case name consistent with itself. No pattern inconsistency exists.

Tool Count3/5

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.

Completeness5/5

For its stated domain of compacting noisy command output, the tool covers the essential functionality. No obvious gaps for its intended use.

Maintenance

ActivityStale
ResponsivenessWithin a week

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

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    Filters 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.
    -
  • A
    license
    A
    quality
    A
    maintenance
    An 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.
    5
    359
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Reduces log files to remove noise and duplicate information, cutting tokens by 70-90% for AI agents, preserving only errors, warnings, and unique events.
    52
    MIT

Latest Blog Posts

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