Skip to main content
Glama

readscout

CI License: MIT

Local models read your files for your coding agent. When Claude Code or Codex needs facts from big files, a long log or a whole folder, it asks readscout instead of reading everything itself. A small model on your own GPU reads the files and answers in a few lines, and every claim comes with a quote that readscout checked word for word in the source, with its real file:line. The quote and the line are proven; the sentence next to them is still the model's reading, so your agent opens the cited lines before any decision. Your agent keeps its context window (and your usage quota) for the real thinking. Nothing ever leaves your machine.

Version française

> local_ask(["app.js"], "Which POST routes are registered WITHOUT passportConfig.isAuthenticated?")

[local_ask · gemma4:26b · 1 chunk(s), 21 KB read locally, 23 s · 18 verified quote(s), 0 dropped (quote not found in source) · quotes are verified, sentences are the model's]
- app.js:253 : The POST route '/login' is registered without passportConfig.isAuthenticated. « app.post('/login', loginLimiter, userController.postLogin); »
- app.js:256 : The POST route '/login/2fa' is registered without passportConfig.isAuthenticated. « app.post('/login/2fa', login2FALimiter, userController.postTwoFactor); »
- app.js:269 : The POST route '/signup' is registered without passportConfig.isAuthenticated. « app.post('/signup', userController.postSignup); »
...

That is a real run on hackathon-starter's 101-route app.js: 21 KB stayed out of the agent's context, 18 of the 19 matching routes came back, none wrong, every line number real. The question contains "WITHOUT", so readscout picked the bigger model by itself.

Contents

Related MCP server: gus

What it does

readscout is an MCP server with three tools, plus a skill that tells your agent when to use them:

Tool

Your agent gives it

It gets back

local_ask(paths, question)

files or folders (up to 1.5 MB) and a question

a few findings, each with a verified quote and its real file:line (mode="summary" adds a short summary)

local_digest(path)

a long log or command output

the root cause and the distinct failures, with verified quotes

local_edit(paths, instruction, gate)

files, a precise change, and check commands (your tests)

APPLIED + the diff if your checks pass, else ESCALATE with the files restored byte for byte

How the answers stay trustworthy:

  • the model's output is constrained by a JSON schema, so it always parses;

  • any finding whose quote is not found in the source is dropped; line numbers are computed by readscout, never by the model;

  • large inputs are split into chunks instead of being refused; logs are pre-filtered (errors with context, start, end, no duplicates);

  • negative questions ("without", "not", "missing") go to the bigger model automatically, because small models get them wrong;

  • an edit is kept only if your tests pass;

  • models free your RAM and VRAM by themselves, whichever engine runs them (Ollama, or llama.cpp's llama-server, which readscout starts and stops itself): they unload one minute after the last call, and as soon as the agent session ends. Nothing to stop by hand (readscout stop frees memory at once).

Why

Every turn of an agent session re-sends the whole conversation, so each big file or log your agent reads keeps costing tokens until the session ends. Most of that reading is mechanical: finding where something is, listing what matches a pattern, spotting the error in a log. A small local model does that well if it must prove what it says.

Earlier "delegate to a local model" setups (including the one this project replaces) failed for measurable reasons: they delegated judgement (code review, fact checking), refused large inputs, and cost the agent more tokens to drive than doing the task itself. readscout delegates reading only, adapts to any input size, and returns a short receipt. The story and the numbers: docs/DESIGN.md and docs/BENCHMARK.md.

Requirements

  • Windows, macOS or Linux.

  • A coding agent: Claude Code and/or Codex.

  • Ollama to run the models (the installer can install it for you).

  • Hardware: a GPU with 6 GB of memory or more is recommended (NVIDIA, AMD, or Apple silicon), and 16 GB of RAM. With 8 GB of VRAM and 32 GB of RAM you get the best measured setup. It also runs on CPU only, slowly.

  • Disk: 7 to 25 GB for the models, depending on your machine.

  • Optional, only to read big inputs faster with the 26B model: llama.cpp (llama-server; the installer does not install it, see Faster with llama.cpp). It reuses the model files Ollama already downloaded. On an NVIDIA GPU take a CUDA build (about 150 MB, plus about 400 MB of CUDA runtime on Windows): CUDA 13 builds need NVIDIA driver 580 or newer (nvidia-smi shows yours), take a CUDA 12 build for an older driver (NVIDIA's compatibility table). The Vulkan build that winget install llama.cpp installs ran slower than Ollama on an NVIDIA card. AMD (ROCm or Vulkan build) and Apple silicon (Metal build) have not been measured: compare with readscout bench.

Installation

Pick one option. A sets up everything for Claude Code and Codex. B is the quickest way if you only use Claude Code. C is the same as A, done by hand.

Windows (PowerShell):

irm https://raw.githubusercontent.com/Anarchiejs/readscout/main/install.ps1 | iex

macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/Anarchiejs/readscout/main/install.sh | sh

The installer asks before installing anything:

  1. uv, a Python manager from Astral (it brings its own Python; you need nothing else);

  2. Ollama, if it is missing (winget on Windows, Homebrew on macOS, the official script on Linux);

  3. readscout itself;

  4. then it opens the setup page in your browser (http://127.0.0.1:8765/setup):

    • Your machine: GPU memory and RAM are detected and pre-filled; adjust the sliders (VRAM 6-24 GB, RAM 16-64 GB) if needed;

    • Models: the models recommended for that machine, each with an Install button (one click, with a progress bar), then Use these models;

    • Coding agents: Connect Claude Code and/or Codex (registers the MCP server and copies the skill);

    • Check: everything should be green.

Restart Claude Code / Codex, and continue with First steps.

Option B: Claude Code plugin

For Claude Code only. You need uv and Ollama installed first. In Claude Code, run:

/plugin marketplace add Anarchiejs/readscout
/plugin install readscout@readscout

The plugin brings the skill and the MCP server (started with uvx, nothing else to install). Then, in a terminal, download the models:

uvx --from https://github.com/Anarchiejs/readscout/releases/download/v0.1.6/readscout-0.1.6-py3-none-any.whl readscout setup

That opens the same setup page as option A: install the models there (skip "Coding agents": the plugin already did it). Restart Claude Code.

Tip: to have a short readscout command for later, install it once with uv tool install https://github.com/Anarchiejs/readscout/releases/download/v0.1.6/readscout-0.1.6-py3-none-any.whl.

Option C: manual install

# 1. Ollama: https://ollama.com/download (then make sure it is running)
# 2. uv:     https://docs.astral.sh/uv/getting-started/installation/
# 3. readscout
uv tool install https://github.com/Anarchiejs/readscout/releases/download/v0.1.6/readscout-0.1.6-py3-none-any.whl

# 4. models recommended for your machine (see `readscout hardware` first if you are curious)
readscout pull

# 5. connect your agent(s)
readscout install-agent claude
readscout install-agent codex

# 6. check
readscout doctor

Restart Claude Code / Codex.

First steps

  1. Check the setup: readscout doctor must end with All good. (plugin users: use the uvx ... readscout form above).

  2. Open any project in Claude Code or Codex.

  3. Ask something that needs a lot of reading, in your own words. For example:

    • "Which API routes in src/routes don't check authentication?"

    • "Where is the session expiry handled in this repo?"

    • "Summarize what the lib/ folder does."

    • "Run the tests and tell me why they fail" (the agent saves the output to a file and digests it).

  4. Watch the agent call local_ask or local_digest and get a short receipt instead of opening every file. The first call loads the model into memory (10-30 s); later calls are faster.

  5. See what it saved: readscout stats, or readscout dashboard for the usage page.

You can also call the tools from a terminal, without any agent, to see what they return:

cd /path/to/my-app
readscout ask src -q "Which functions read environment variables?"
readscout digest build.log

Everyday use

You keep working as usual: the skill tells the agent when to delegate. It uses readscout for:

  • facts spread over files it has not read yet (more than a few hundred lines in total);

  • understanding a module or folder without reading it;

  • long logs, test or build output;

  • small, fully specified mechanical edits (docstrings, type hints, renames, a new parameter, test scaffolding), always with your tests as the gate.

It keeps for itself: anything a quick grep answers, short files it reads anyway, and every judgement (code review, "is there a bug", architecture, real-world facts).

Things you may see in a receipt:

  • retried with quality model: the fast model found nothing quotable, the bigger one was used;

  • quality model ... not installed, used ...: install it with readscout pull <model> for better answers;

  • The list may be incomplete: the agent should narrow the question or add a grep;

Commands

readscout setup                        open the setup page
readscout doctor                       check that everything is installed and wired
readscout hardware                     detected GPU/RAM and recommended models
readscout pull [MODEL ...]             download models (default: the recommended ones)
readscout install-agent claude|codex   register the MCP server and the skill (uninstall-agent to undo)
readscout ask PATH... -q QUESTION      run local_ask from the terminal (--summary, --quality)
readscout digest PATH                  run local_digest from the terminal
readscout edit PATH... -i TEXT --gate "CMD"   run local_edit from the terminal
readscout folders [add|remove DIR...]  limit the local models to these folders (no list: any folder)
readscout gate on|off                  allow or forbid local_edit's gate commands
readscout engine [ollama|llamacpp]     which engine runs each model (see "Faster with llama.cpp")
readscout stats                        what was read locally instead of by your agent
readscout dashboard                    usage page
readscout stop                         unload every model now, on both engines (they also unload by themselves)
readscout bench                        measure your models on the public benchmark

Settings and usage data live in your user folder, never in the package: %APPDATA%\readscout on Windows, ~/Library/Application Support/readscout on macOS, ~/.config/readscout on Linux (config.json, metrics.jsonl, and with llama.cpp llamacpp.json, llama-server.log).

Models

Chosen per machine from catalog.json, measured with the public benchmark:

Your machine

Fast

Quality

less than ~6 GB VRAM

gemma4:e2b

gemma4:e2b

6-7 GB VRAM

gemma4:e4b

gemma4:e4b

8-9 GB VRAM, 16 GB RAM

gemma4:e4b

gemma4:12b (part of it runs from RAM)

10 GB VRAM or more, 8 GB RAM or more, less than ~30 GB RAM

gemma4:e4b

gemma4:12b

6-14 GB VRAM, 32 GB RAM or more

gemma4:e4b

gemma4:26b (MoE, experts in RAM)

15 GB VRAM or more, 16 GB RAM or more

gemma4:e4b

gemma4:26b, mostly on the GPU

The context size follows the machine too: 32k tokens by default, 64k for the fast model from 12 GB of VRAM, and for the quality model from 24 GB (26B) or 14 GB (12B). A bigger context means fewer chunks on big files; it has not been benchmarked yet, and you can change it in config.json (models.<tier>.ctx).

On an RTX 4060 Ti 8 GB + 32 GB RAM (docs/BENCHMARK.md): gemma4:12b and gemma4:26b score 0.94 and 0.93 on 25 reading tasks from four pinned open-source repositories (about 24 and 23 s per task), gemma4:e4b 0.83 with 7/7 edits (about 6 s). Negative questions are where the small models fail (gemma4:e4b 0.28, gemma4:e2b 0.12, the bigger ones 0.88), which is why readscout sends them to the quality model. Measure your own machine with readscout bench and share the table in an issue.

Faster with llama.cpp (optional)

Ollama is the default engine and stays the best choice on most machines. llama.cpp reads big prompts about twice as fast with a mixture-of-experts quality model, but writes more slowly. Measured on an RTX 4060 Ti 8 GB + 32 GB RAM (Ollama 0.40.3, llama.cpp b11636 CUDA, the same GGUF files, Gemma 4, full results):

Ollama

llama.cpp (CUDA)

gemma4:26b, reading a prompt

554-566 tokens/s

1,008-1,205 tokens/s (--n-cpu-moe 30)

gemma4:26b, writing

42-45 tokens/s

24-25 tokens/s

gemma4:26b, a 181 KB folder, new files (3 chunks of ~25k tokens)

181 s

127 s

gemma4:26b, the same folder asked again (cached prompt)

30 s

54 s

gemma4:26b, public benchmark (small inputs)

0.93, 23 s/task, edits 9.7 s

0.94, 23 s/task, edits 14 s

gemma4:12b, public benchmark

0.94, 24 s/task, edits 6/7 in 12 s

0.93, 50 s/task (2x slower), edits 6.8/7 in 25 s

gemma4:e4b, public benchmark

0.83, 5.8 s/task, edits 7/7

0.86, 16.9 s/task (3x slower), edits 6.8/7

So llama.cpp pays off for one thing: reading new big inputs with the 26B (here 1.4x faster overall, 2x on the prompt alone). It loses when the same files are asked about again (Ollama keeps the start of the prompt in cache and writes faster), and it is slower for the fast and the 12B models. That is why each model can run on its own engine. The Vulkan build that winget install llama.cpp installs was slower than Ollama on an NVIDIA card: with NVIDIA, take the CUDA build from the releases (llama-bXXXX-bin-win-cuda-13.x-x64.zip plus the matching cudart-...zip; see Requirements for the driver). On a machine with an integrated GPU too, add --args "--device CUDA0" (or Vulkan0) so the model is not split onto it; readscout doctor shows the device ids.

readscout engine llamacpp --quality ollama:gemma4:26b --binary path/to/llama-server --args "--n-cpu-moe 30"
readscout engine                                         # fast: ollama gemma4:e4b, quality: llamacpp ...
readscout doctor
readscout bench --models gemma4:26b,llamacpp:quality     # compare both engines on your machine

Only the models you name move to llama.cpp: above, the fast model stays on Ollama (--fast ollama:gemma4:e4b would move it too, --quality ollama moves the quality model back). ollama:<model> reuses the file Ollama already downloaded (nothing to download again); a .gguf path works too. readscout then starts llama-server itself on a free loopback port (flash attention, 8-bit KV cache, 2048 micro-batch, Ollama's repeat penalty), keeps a single model loaded, shared by all your agent sessions, and stops it after the same idle delay as Ollama (one minute) or when the session ends; readscout stop stops it at once. On an 8 GB card the two engines cannot both hold a model, so they take turns: before llama.cpp loads a model, readscout unloads Ollama's, and before an Ollama call it stops its idle llama-server (never one in the middle of another session's request; switching costs a model load, a few seconds from RAM). Extra flags go in --args, for all models, or in config.json under llamacpp.models.<tier>.args for one (the 26B above used ["--n-cpu-moe", "30"]). Already running your own llama-server? Give its address instead: --fast http://127.0.0.1:8080 (readscout then never starts or stops it). Every model back on Ollama: readscout engine ollama (your llama.cpp models are kept: readscout engine llamacpp brings them back). Restart your agent after switching.

Troubleshooting

Symptom

Fix

Anything odd

readscout doctor lists what is missing, with the command that fixes it

"Ollama is not installed" / "Ollama did not start"

install or start Ollama (on Windows and macOS, readscout starts the app by itself)

"llama-server not found" or "model file not found"

you chose llama.cpp for a model: install it or fix the path (readscout engine), or go back with readscout engine ollama

llama.cpp is slower than Ollama on an NVIDIA GPU

readscout doctor lists the devices llama-server sees: with only Vulkan0 or no GPU, take the CUDA build

llama.cpp split the model onto your integrated GPU

readscout engine llamacpp --args "--device CUDA0" (the id doctor shows for your GPU)

"Model ... is not installed yet"

readscout pull

A model fails to load with "out of memory" or "Gemma4Assistant requires ctx_other" although the GPU looks free

a llama-server.exe from Ollama's folder (...\Ollama\lib\ollama) was left running by an earlier Ollama session and still holds the GPU: quit Ollama from its tray icon, end that process, start Ollama again (seen on Windows after Ollama restarted itself during a long run)

The agent never uses readscout

restart the agent after installing; check with readscout doctor that it is connected

Answers are slow

normal on small GPUs for the quality model (20-60 s); the fast model answers in seconds

Bigger models run out of memory on Windows

setup page, Apply under "Recommended Ollama settings", then restart Ollama

Security and privacy

  • Models run on 127.0.0.1 only; any other endpoint is refused in code, and so are Ollama cloud models (by name and when Ollama reports them as served by a remote host). readscout never calls an online model, even as a fallback. If you use Ollama itself with cloud features, that is outside readscout; the Ollama settings it offers also switch them off (OLLAMA_NO_CLOUD=1). With the optional llama.cpp engine, readscout starts llama-server itself, bound to 127.0.0.1 on a free port with a random secret key (so a web page cannot query it), only for the .gguf files you configured; a server you run yourself must be on 127.0.0.1 too.

  • The model has no tools: it reads the text readscout gives it and returns JSON. Only readscout reads files: the ones your agent names, by default in any folder (nothing to register). .env*, .git, keys, credential files and binaries are always refused whatever the letter case; common secrets (provider keys and tokens, JWTs, passwords in URLs, Authorization headers, password/secret/token assignments, also in JSON) are masked before reaching the model, and local_edit refuses files that contain one. Masking is pattern based: it cannot catch every secret, so keep real credentials out of your projects.

  • If you restrict your agent (no Bash, Read limited to some folders in Claude Code's permissions), readscout does not see those rules: it reads what the agent names and runs its gate commands. To keep the same limits, use readscout folders add <folder> (the local models then only read and write inside the listed folders; readscout folders shows the list, readscout folders remove <folder> drops one) and readscout gate off (local_edit then refuses any gate command). readscout doctor shows both settings.

  • File contents and model answers are treated as data, never as instructions. Model-written text is flattened to short single lines in the receipts, but it stays unverified: the agent checks the cited lines before deciding.

  • local_edit writes atomically, never overwrites a file that changed while the model was working, and restores only what it wrote. Its gate commands are run as you, without a shell, in the project folder: they are chosen by the calling agent, exactly like the tests it would run itself.

  • Stored locally, in your user folder: config.json and metrics.jsonl (tool, model, sizes, timings and counts; never file contents, questions or answers), and with llama.cpp llamacpp.json (the running server's process, port and last use) and llama-server.log (model loading messages and timings; no file contents). Nothing is sent anywhere. Agent installers back up ~/.codex/config.toml once (config.toml.readscout-bak) and only touch the mcp_servers.readscout entry.

  • The setup page listens on 127.0.0.1, checks Host and Origin, and requires a per-session token for every change. The "Recommended Ollama settings" button saves permanent user environment variables on Windows after asking.

  • Installers ask before installing uv or Ollama (and install nothing when no terminal is available unless you set READSCOUT_YES=1). Each release publishes SHA256SUMS for the wheel, the sdist and the installers.

Details and reporting: SECURITY.md.

Limits

  • Small models are good readers and poor authorities: do not delegate code review, bug hunting or fact checking.

  • A verified quote proves the line exists, not that the model understood it; the agent opens the cited lines before any decision (the skill says so).

  • Lists can be incomplete (the receipt says so when a cap was hit); when completeness matters, add a targeted grep.

  • Lines longer than 4000 characters (minified files) are cut and the receipt says so; only the start was read.

  • A quote may differ from the source by whitespace and by line breaks between adjacent lines, nothing else.

  • Tests run without Ollama or a GPU (a fake model); real-model checks (scripts/e2e.sh, scripts/e2e.ps1) are run by hand before a release and are not part of CI.

Uninstall

readscout uninstall-agent claude      # or: /plugin uninstall readscout@readscout
readscout uninstall-agent codex
uv tool uninstall readscout

Models stay in Ollama (ollama rm gemma4:26b); settings stay in the user folder listed under Commands.

Contributing

Benchmark reports from other GPUs, bug reports and pull requests are welcome: see CONTRIBUTING.md. Roadmap: more model families in the catalog, GGUF downloads for the llama.cpp engine from the setup page, more benchmark tasks.

License

MIT

Available Tools

3 tools
local_askA
Read-onlyIdempotent

Read files or directories with a local model so you don't have to; get back a short answer. Use instead of Read/Grep when you need facts from large or many files but not the files themselves ("which routes lack auth", "where is X handled", "what does this module do"). Each fact comes with a quote verified verbatim in the source and its real path:line; facts the model could not quote are dropped. mode='summary' adds a short unverified summary. quality: leave unset (auto: the bigger model for negative questions or when the fast one finds nothing), True to force it. Do not use for decisions (security, correctness) without opening the cited lines.

NameRequiredDescriptionDefault
modeNofind
pathsYes
qualityNo
questionYes
max_itemsNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior on top: facts must be quote-verified verbatim against the source, unquotable facts are dropped, mode='summary' yields an explicitly unverified summary, and quality auto-escalates for negative questions or empty results. This is real information an agent cannot get from the annotations.

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?

Front-loaded with purpose, then usage, then behavioral guarantee, then parameter notes, then a safety caveat. Every sentence carries content, though the parenthetical-heavy middle becomes dense and 'so you don't have to' is pure framing.

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 5-parameter tool with an output schema and full annotation coverage, the description supplies the missing pieces: routing versus Read/Grep, trust model of returned facts, mode/quality semantics, and a decision-use caveat. Return values need not be explained since an output schema exists.

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 0%, so the description carries the full burden, and it does explain the two least-obvious parameters: what mode='summary' changes about trustworthiness and what unset vs. True quality means. However, max_items is never mentioned and paths/question are only implied by the examples, leaving gaps the schema does not fill.

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 concrete verb+resource+output: 'Read files or directories with a local model... get back a short answer.' It clearly distinguishes itself from Read/Grep by naming them as alternatives, but it never distinguishes itself from its actual siblings local_digest and local_edit, which is the overlap an agent must resolve.

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?

It gives explicit when-to-use with concrete triggering questions ('which routes lack auth', 'where is X handled'), names the alternative (Read/Grep) and the condition that selects this tool (need facts from large/many files but not the files themselves), and states a when-not ('Do not use for decisions... without opening the cited lines').

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

local_digestA
Read-onlyIdempotent

Triage a long log or command output file (CI log, test output, server log) locally. Returns the root-cause error and distinct failures with verified path:line quotes, instead of loading the whole file into context. Tip: redirect a noisy command to a file, then digest it.

NameRequiredDescriptionDefault
pathYes
focusNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value: it explains the tool reduces context load and returns verified path:line quotes rather than raw content. It does not state limits (file size, binary/unsupported input) or behavior on an unreadable path.

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?

Two sentences, front-loaded with the purpose and output value before the practical tip. Every sentence contributes; the only minor slack is that the three parenthetical log examples could be trimmed.

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?

With an output schema present, return values need not be described, and annotations already cover the safety profile. The definition is nearly complete for a 2-parameter read-only tool, with the sole real gap being the undocumented 'focus' parameter.

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?

Schema description coverage is 0% for both parameters, so the description carries the full burden. 'Log or command output file' weakly implies the required path, but the optional 'focus' parameter is never mentioned or explained anywhere, leaving an agent unable to know what it does or when to set it.

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 gives a specific verb (triage) and resource (a long log or command output file), with concrete examples (CI log, test output, server log). It clearly reads as distinct from local_ask and local_edit, but it never names or contrasts those siblings, so the differentiation is implicit rather than explicit.

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 tip 'redirect a noisy command to a file, then digest it' supplies a concrete trigger condition, and 'instead of loading the whole file into context' explains the tradeoff that motivates use. There is no stated when-not-to-use case or named alternative, so it stops short of full routing guidance.

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

local_editA
Destructive

Apply a small, fully specified mechanical change with a local model (docstrings, comments, type hints, renames, boilerplate, test scaffolding, applying a decided pattern). Pass paths, not contents: do not Read the files first. gate = commands (argv lists, at most 5, no shell, run with the user's rights: only the project's own tests or linters) that must pass, e.g. [["python","-m","pytest","-q"]]; if they fail after one retry the files are restored and the result is ESCALATE. Returns APPLIED with the diff to review, or ESCALATE. Never for design, debugging or security-sensitive code.

NameRequiredDescriptionDefault
gateNo
pathsYes
instructionYes

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the failure path: gate commands run with the user's rights, are limited to at most 5 argv lists with no shell, and on failure after one retry the files are restored and the result becomes ESCALATE. It also states the return states (APPLIED with diff, or ESCALATE), all of which is critical context for a destructive, non-idempotent mutation.

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?

Front-loads the core purpose and every sentence carries information. The gate sentence is a dense run-on stacking parentheticals and semicolons, which slightly hurts scannability, but nothing is wasted.

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 3-param destructive tool with an output schema, the description covers the safety profile, the gating/rollback mechanics, argument shape, and exclusions. An agent has everything needed to invoke it correctly; return values are additionally clarified beyond the schema.

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 0%, so the description must compensate, and it does for gate (argv lists, max 5, no shell, run with user's rights, concrete example) and for paths ('pass paths, not contents'). The instruction parameter is only implicitly characterized via 'fully specified mechanical change', leaving a small 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+scope ('Apply a small, fully specified mechanical change with a local model') and enumerates the qualifying edit types (docstrings, comments, type hints, renames, boilerplate, test scaffolding). It is unambiguous about what kind of work it does, though it never names or contrasts with its siblings local_ask/local_digest.

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?

Gives clear when-not guidance ('Never for design, debugging or security-sensitive code') and workflow direction ('Pass paths, not contents: do not Read the files first'), plus the condition for supplying a gate. It stops short of naming which sibling to use instead for the excluded cases.

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. 3 tool updatesv0.1.0
    • First observedlocal_ask
    • First observedlocal_digest
    • First observedlocal_edit

TDQS

A4.1/5.0

Scored across 3 tools

Disambiguation4/5

local_ask and local_digest both use a local model to extract info from files, which creates mild overlap, but their descriptions clearly separate general code Q&A from log/command-output triage. local_edit is unmistakably distinct as a mutation tool with its own gating semantics.

Naming Consistency5/5

All three tools share the same local_ prefix followed by a single verb/noun (ask, digest, edit), giving a fully predictable pattern. No mixing of conventions.

Tool Count5/5

Three tools is a tight, well-scoped set for a focused helper: query files, triage logs, and apply mechanical edits. Each tool is substantial and earns its place with no redundancy.

Completeness4/5

The surface covers the core read/query, triage, and edit lifecycle for local model assistance, which matches the stated purpose. There is no explicit multi-file batch or non-mechanical edit path, but that exclusion appears deliberate and documented rather than a gap.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to search and ask questions about a local codebase with citations, using BM25 and optional embeddings, all offline.
    4 npm
    1
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI coding agents to retrieve only the specific code sections that answer their questions, drastically reducing context usage while running fully locally.
    1
    MIT
  • F
    license
    Not graded
    quality
    B
    maintenance
    Enables AI coding agents to retrieve focused, bounded repository context locally and read-only, reducing token usage while never modifying the repository or executing its code.
    -
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI coding agents to interrogate a local repository deterministically for symbols, dependencies, call paths, routes, tests, and Git impact, returning verified structured evidence with exact line citations instead of requiring the whole codebase to be read.
    56 PyPI
    4
    MIT