Skip to main content
Glama
avikchakraborty060-create

./skimread

by avikchakraborty060-create
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

skimread — skim before you read

A lossless context guard for AI coding agents. Zero dependencies, runs entirely on your machine, MIT licensed. Works with Claude Code out of the box, and with any other agent (Codex, Cursor, Aider, Copilot, your own) through a CLI and an MCP server.

What is it?

When you use an AI coding agent, you pay for every token it reads. Most of that money goes to two things the agent does not actually need:

  1. Reading big files whole. The agent wants one function and reads all 2,000 lines of the file to find it. Next session it does it again.

  2. Reading noisy command output. pytest -v prints 1,500 PASSED lines to tell you about 2 failures. npm install prints 40 deprecation warnings. cargo build lists every crate it compiled.

skimread sits between the agent and those two sources and hands the agent a skim first:

  • For files: an outline instead of the file. When the agent is about to read a large file, skimread gives it a map of the file (functions, classes, headings, keys, each with its line range) and says "read only the slice you need". The agent then reads 60 lines instead of 2,000.

  • For commands: a digest instead of the dump. Noisy commands run through skimread. The agent sees the errors, the failing tests, the stack frames in your code, and the summary line. The 1,500 PASSED lines are folded into one line that says so.

The key word is lossless. Nothing is thrown away. Every command's full output is kept on your disk, and every digest ends with a handle (skimread show 42, skimread show 42 120-180, skimread show 42 --grep TypeError). Every outline tells the agent exactly which line range to read next. The agent is never stuck and never has to re-run a build to see what it missed.

Why not one of the existing output compressors?

Tools that compress shell output already exist (RTK, token-saver, condense). They share two limits. They cannot touch the agent's own file-reading tool, which is the bigger token sink. And they are lossy: when the compressor drops the one line the agent needed, the agent re-runs the command, and an independent benchmark found that this can cost more than not compressing at all. skimread guards file reads too, and keeps everything retrievable.

What it is not

  • Not a cloud service. No network calls, no accounts, no telemetry. ~/.skimread is the whole state.

  • Not an LLM. Everything is deterministic parsing and folding, so it runs in milliseconds and costs nothing.

  • Not a summariser that guesses. It never rewrites a line; it only hides lines it can name and count, and tells you how to get them back.

Related MCP server: Smart Context MCP

Numbers

Measured on real tool output (fixtures in tests/fixtures, reproduce with python bench/bench.py). Token counts are estimates (chars / 3.6).

Command output

lines

tokens in

tokens out

saved

pytest -v (1,504 tests, 2 failing)

1546

33,876

473

99%

vitest --reporter=verbose (579 tests, 3 failing)

653

7,751

698

91%

pytest (65 tests, 3 failing, 60 warnings)

294

3,451

496

86%

npm install (649 packages, 23 deprecation warnings)

41

1,048

204

81%

cargo build (37 crates, 3 warnings)

61

559

254

55%

go test -v (1 fail, 1 panic)

35

301

137

54%

tsc (48 errors in 8 files)

48

1,087

628

42%

cargo test (1 fail, backtrace)

68

713

487

32%

cargo build (2 errors)

39

408

411

-1%

vitest (13 files, 3 failing)

76

613

628

-2%

The last two rows are the point: when the output is already pure signal (a short build with two errors), skimread leaves it alone. Savings come from noise, never from hiding failures.

File read

lines

full read (tokens)

outline (tokens)

saved when the agent then reads a 60-line slice

skimread/outline.py

598

7,648

477

84%

skimread/formats.py

463

4,961

569

76%

skimread/cli.py

368

4,086

357

75%

A 4,063-line Go file (net/http/server.go, ~36k tokens) becomes a ~600-token map of structs and methods with line ranges. skimread stats shows what it has saved you so far, in tokens and dollars.

How to use

1. Install (30 seconds)

Needs Python 3.9 or newer, nothing else.

pipx install skimread          # recommended: isolated, on your PATH
# or: uv tool install skimread
# or, inside any Python environment: pip install skimread
skimread --version

Latest development version straight from GitHub: pipx install git+https://github.com/avikchakraborty060-create/The-top-innovation.

Everything skimread stores lives under ~/.skimread with owner-only permissions and is pruned after 7 days or 300 runs.

2. Claude Code: one command

skimread setup claude            # global: ~/.claude/settings.json
skimread setup claude --project  # or per project: .claude/settings.json

Restart Claude Code. That is all. From then on:

  • When Claude tries to Read a file over 400 lines (or 16 KB) without a line range, it gets the outline and the instruction to read a range instead. A ranged read is always allowed. If Claude asks for the same whole file a second time in the session, it gets it, so it is never stuck.

  • When Claude runs a command known to be noisy (npm, pytest, cargo, go, tsc, docker, git diff, find, and about 100 others) the command is rewritten to run through skimread run. Claude sees the digest and the handle. The permission rule Bash(<path-to-skimread>:*) is added so this causes no extra prompts.

This is what Claude sees instead of a 2,014-line file:

skimread: src/server.py is 2,014 lines (~20k tokens). Read only the part you need: call Read again
with offset and limit chosen from this outline. Any Read that sets offset or limit is allowed; ...
Outline: 2,014 lines, ~20k tokens (python)
      1-38  imports 12 import statements
    41-118  class Config
    44-58     def __init__(self, path: str) -> None
    61-90     def load(self) -> dict
   121-410  class Server(Base)
   123-140    def __init__(self, cfg: Config)
   142-229    def handle_request(self, req: Request) -> Response
   ...

And this is what Claude sees after pytest -v on a suite of 1,504 tests:

$ pytest -v test_many.py  ·  exit 1 in 1.2s
============================= test session starts ==============================
  (1502 passing/skipped tests hidden)
test_many.py::test_some_fail[1] FAILED                                   [ 99%]
test_many.py::test_some_fail[3] FAILED                                   [100%]
=================================== FAILURES ===================================
______________________________ test_some_fail[1] _______________________________
...
E       AssertionError: role mismatch for user 1
E       assert 'dev' == 'ops'
test_many.py:10: AssertionError
=========================== short test summary info ============================
FAILED test_many.py::test_some_fail[1] - AssertionError: role mismatch for user 1
FAILED test_many.py::test_some_fail[3] - AssertionError: role mismatch for user 3
======================== 2 failed, 1502 passed in 0.98s ========================
[skimread #42: 1546 lines, ~34k tok → 473. Full/slice/search: skimread show 42 [A-B | --grep RE]]

Tuning:

skimread setup claude --wrap all     # route every safe Bash command through skimread
skimread setup claude --wrap off     # Read guard only, leave Bash alone
skimread setup claude --uninstall    # remove the hook and the permission rule
skimread config read_threshold_lines 600   # guard only files longer than this (default 400)
skimread config budget 4000                # digest size in characters (default 6000)
skimread setup print                       # just print the settings.json snippet to paste yourself

Safety: the Bash wrapper never touches commands that change shell state (cd at the end, export, source), redirect to files, run in the background, look interactive, or are destructive or privileged (rm, sudo, git push, git commit, curl | sh, and so on). Those run exactly as Claude wrote them, under your normal permission rules. A leading cd dir && … is kept outside the wrapper so the working directory still changes.

3. Codex, Cursor, Aider, Copilot, or your own agent

Any agent that can run shell commands can use skimread through the CLI. Put this in the agent's rules file (AGENTS.md, .cursorrules, a system prompt); skimread setup agents prints a ready-made snippet:

skimread outline src/server.py           # map of the file with line ranges
skimread read src/server.py 142-229      # numbered slice
skimread run -c "npm test"               # digest + handle   (shorthand: skimread npm test)
skimread show 42                         # full stored output
skimread show 42 300-360                 # slice
skimread show 42 --grep "Error" -C 3     # search with context
skimread list                            # recent runs

Agents that speak MCP can use it as a server instead. skimread mcp is a stdio MCP server with tools run, show, outline, read, list; skimread setup mcp prints the config block for mcpServers. Anything on stdin works too: cmd 2>&1 | skimread pipe --cmd "cmd".

4. See what it saved you

skimread stats                 # tokens and dollars saved, all time, by format
skimread stats --price 15      # use your model's input price per million tokens
skimread stats --json

How it works

  1. Normalise. ANSI colours and cursor codes are stripped, \r progress bars resolve to their final state, backspaces are applied.

  2. Format-aware reduction. Reducers for pytest, jest/vitest/mocha, cargo, go, npm/yarn/pnpm/bun, pip/uv/poetry, docker, tsc, git diff, and file/listing commands drop only what carries no decision value: PASSED lines, Compiling lines, deprecation warnings (counted), stdlib stack frames. Everything else stays. Unknown tools get the generic path: progress noise removed, exact duplicates counted (line (x5)), runs of near-identical lines folded (… 847 similar lines (159-1005) …).

  3. Scoring and budget. Lines are scored (errors and stack frames high, summaries medium). If the reduced output still exceeds the budget, the head, the tail, and windows around the highest-scored lines are kept; every cut is replaced by … [768 lines omitted (45-812) — skimread show 42 45-812] ….

  4. Spool. The full normalised output is written to ~/.skimread/out/<id>.txt before the digest is produced, so the handle in the footer always works.

  5. Outline. Python via the ast module (exact signatures and ranges); JS/TS, Go, Rust, Java/Kotlin/C#/Swift, C/C++, PHP, CSS via declaration regexes plus brace matching; Ruby/Elixir/Lua via indentation; Markdown headings; JSON/YAML/TOML keys; CSV shape; log files (time span, error line numbers); Makefiles, shell functions, SQL statements. Huge files fold members into their parents and truncate with a note rather than pretending to be complete.

Honest limitations

  • Token counts are estimates (chars / 3.6), not tokenizer output. Ratios are what matter and they are unaffected.

  • Outlines for brace languages are regex-based. They are meant for navigation, not correctness; a weird formatting style can miss a symbol. Grep still works.

  • The Read guard costs one extra tool round-trip for files just over the threshold. The default (400 lines) is chosen so the outline plus a slice is still much cheaper than the file; raise it if your agent mostly needs whole files.

  • The Bash wrapper runs the command through bash -c in a child process. Shell functions and aliases defined in Claude Code's persistent shell are not visible to it (environment variables and the working directory are).

  • Only Claude Code has a hook that can intercept the agent's native Read. Other agents get the same capability through the CLI/MCP tools plus an instruction in their rules file.

Development

git clone https://github.com/avikchakraborty060-create/The-top-innovation && cd The-top-innovation
pip install -e ".[dev]"
python -m pytest -q          # 68 tests, < 1 s
python bench/bench.py        # the tables above

Add a format: write a reduce_<tool>() in skimread/formats.py that drops or folds noise lines and sets scores, register it in detect(), drop a real output sample into tests/fixtures, and add a row to tests/test_formats.py that states what must survive. Add a language: a pattern list in skimread/outline.py.

Contributions of real-world fixtures are the most valuable thing you can send: the reducers are only as good as the outputs they have seen.

License

MIT.

Available Tools

5 tools
listC

List recent runs stored by skimread (id, command, exit code, size).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It discloses the shape of returned records (id, command, exit code, size), which is useful, but says nothing about ordering guarantees, what 'recent' means, default limits, or pagination behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One tight, front-loaded sentence with no wasted words. It is efficient, though arguably terse enough to omit needed detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter list tool with no output schema or annotations, naming the returned fields covers a lot of ground, but the unexplained 'limit' parameter and undefined 'recent' semantics leave real gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single 'limit' parameter has 0% schema description coverage and is never mentioned in the description. 'Recent' hints at a cap but gives no meaning, default, or range, so the description does not compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('List recent runs stored by skimread') and even enumerates the returned fields, so the agent knows exactly what it gets. It does not explicitly differentiate itself from siblings like show or run, but the resource is clear enough to distinguish a listing operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of alternatives such as show or run, and no prerequisites or exclusions. The agent must infer that this is the enumeration counterpart to the other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

outlineA

Structural outline of a file: symbols/headings/keys with line ranges, so you can read only the slice you need. Use before reading any file longer than ~300 lines.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose the return shape (symbols/headings/keys with line ranges) plus the fact that it enables selective reading rather than dumping content. It does not cover edge cases (unsupported/binary files, empty outlines) or confirm the non-mutating nature explicitly, so it falls short of full behavioral disclosure.

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?

Two sentences, front-loaded with the core purpose and followed immediately by the actionable usage rule. Every clause earns its place with zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with no output schema, the description supplies what matters: the returned structure, the intended workflow, and the usage threshold. An agent has everything needed to call it correctly; only minor file-type edge cases are unaddressed.

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?

Schema coverage is 0% and the description never explains the sole 'path' parameter, though 'of a file' weakly implies it is a file path. For a single self-evident required parameter this is minimally acceptable, but the description adds no format or constraint detail beyond the schema.

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?

States a specific resource and precisely what it produces: 'Structural outline of a file: symbols/headings/keys with line ranges.' It also distinguishes itself from the read sibling by framing its output as a way to read only the slice you need, so an agent can tell it apart from read/show/list without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use before reading any file longer than ~300 lines' names the trigger condition (file length threshold) and the alternative it should precede (reading). Both when-to-use and the relationship to the competing sibling are explicit, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

readC

Read a line range of a file with line numbers ('start' and 'end' are 1-based, inclusive).

ParametersJSON Schema
NameRequiredDescriptionDefault
endNo
pathYes
startNo

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden and discloses only that output includes line numbers. It says nothing about behavior on out-of-range lines, missing files, permissions, encoding, or the return format, which matters for a file-reading tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that defines the core semantics without waste. It is efficient, though extremely terse for a 3-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and 0% schema description coverage, the description answers the key indexing question but leaves output shape and edge-case behavior unspecified. Adequate minimum but with clear gaps.

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?

Schema coverage is 0%, so the description must compensate, and it does partially by defining 'start' and 'end' as 1-based and inclusive. 'path' and the default when start/end are omitted are left undocumented, so the compensation is incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Read a line range of a file') and even clarifies the output includes line numbers. It does not, however, distinguish itself from the siblings (show, outline, list), which likely also read file content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus 'show' or 'outline', nor on prerequisites or exclusions. Usage must be inferred entirely from the name and the phrase 'line range'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

runA

Run a shell command and return a short, lossless digest of its output (errors, failures and summaries kept; noise folded). The digest ends with an id; use show to fetch any part of the full output without re-running the command.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory (optional)
budgetNoDigest size in characters (default from config, 6000)
commandYesShell command line
timeoutNoSeconds before the command is killed (optional)

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden. It does well to explain the digest behavior, noise folding, the embedded id, and the non-destructive alternative of using `show` instead of re-running. But it says nothing about arbitrary shell execution being potentially destructive, exit-status/failure reporting, timeout side effects, or permission requirements.

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?

Two tightly written sentences, front-loaded with the action and the key behavioral trait (digest vs. raw output), then the follow-up path. No filler.

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?

There is no output schema, so the description must describe the return, and it does explain that the digest preserves errors/failures/summaries and ends with an id usable via `show`. It omits how exit codes or timeouts surface and what the id looks like, which are the remaining gaps.

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?

Schema description coverage is 100%, so `command`, `cwd`, `budget`, and `timeout` are already documented in the schema. The description adds no extra parameter meaning (e.g., what happens when `budget` truncates, or how `timeout` interacts with the digest), so the baseline 3 applies.

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?

States a specific verb and resource ('Run a shell command') plus the distinguishing return behavior (a short, lossless digest rather than raw output). It also names the sibling `show` as the follow-up for full output, so an agent can separate it from the read/list/outline family.

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 clearly routes the agent: use `run` to execute, then use `show` to fetch any part of the full output 'without re-running the command'. That is a concrete alternative and condition. It does not, however, state exclusions (interactive commands, long-running processes) or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

showB

Show the full output of a previous run by id, a line range (e.g. '120-180'), or lines matching a regex with context.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes
grepNoRegex to search for
rangeNo'A-B', 'A:', ':B' or 'A'
contextNoContext lines around grep matches (default 2)

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It describes selection modes (range, grep with context) but omits whether the operation is read-only, whether it has side effects, permission requirements, or error behavior.

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?

A single, front-loaded sentence that efficiently conveys the tool's core action and the three selection modes without any wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter read tool with no output schema and no annotations, the description is minimally adequate: it states what is returned ('full output') and how to filter, but lacks any safety, permission, or error-handling context that an agent might need.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, and the description adds meaning for all parameters: it clarifies 'id' refers to a previous run, gives a range example ('120-180'), and links 'grep' with 'context' as a combined mode. This goes slightly beyond the schema's separate descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb 'Show' and resource 'full output of a previous run', distinguishing it from siblings like read (files) and run (execution). However, it does not explicitly differentiate from outline or list, though the run-output focus is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage after a 'run' by requiring a run id, but provides no explicit when-to-use vs alternatives (e.g., when to use show instead of read or outline). No exclusions or prerequisites are stated.

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.

  1. 5 tool updatesv0.1.1
    • First observedlist
    • First observedoutline
    • First observedread
    • First observedrun
    • First observedshow
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinct action: run executes commands, list shows past runs, show retrieves run output, read reads file line ranges, and outline provides file structure. There is no functional overlap; show and read differ by source (run output vs. file), and descriptions make this clear.

Naming Consistency5/5

All tool names are single, lowercase verbs (show, outline, read, run, list) following a consistent and predictable pattern throughout the set. There is no mixing of conventions like camelCase or noun-based names.

Tool Count5/5

Five tools is well-scoped for a skimreading utility: run, list, show, read, and outline cover the essential workflow without redundancy or bloat. Each tool earns its place and the set is easy to navigate.

Completeness4/5

The surface covers executing commands, browsing runs, retrieving outputs, and inspecting files structurally or by line range, forming a nearly complete lifecycle for the stated purpose. A minor gap is the lack of direct in-file content search (e.g., grep), though this can be worked around by running a shell command via run.

Maintenance

ActivityMaintained
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers

  • siftr

    Bentlybro
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI coding agents to quickly find relevant code, focus reads on important parts of large files, and pick relevant items from long lists, reducing token usage and search time.
    7
    MIT