readscout
Runs and manages the local models used by readscout, including pulling recommended models and unloading them to free RAM and VRAM.
Enables OpenAI Codex to delegate reading tasks to local models, receiving short verified answers with quotes and line numbers instead of consuming its own context window.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@readscoutwhich POST routes in app.js are missing auth checks?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
readscout
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.
> 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
Install: one-line installer · Claude Code plugin · manual
First steps · Everyday use · Commands · Models · Faster with llama.cpp
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 |
| files or folders (up to 1.5 MB) and a question | a few findings, each with a verified quote and its real |
| a long log or command output | the root cause and the distinct failures, with verified quotes |
| files, a precise change, and check commands (your tests) |
|
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 stopfrees 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-smishows yours), take a CUDA 12 build for an older driver (NVIDIA's compatibility table). The Vulkan build thatwinget install llama.cppinstalls ran slower than Ollama on an NVIDIA card. AMD (ROCm or Vulkan build) and Apple silicon (Metal build) have not been measured: compare withreadscout 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.
Option A: one-line installer (recommended)
Windows (PowerShell):
irm https://raw.githubusercontent.com/Anarchiejs/readscout/main/install.ps1 | iexmacOS / Linux:
curl -fsSL https://raw.githubusercontent.com/Anarchiejs/readscout/main/install.sh | shThe installer asks before installing anything:
uv, a Python manager from Astral (it brings its own Python; you need nothing else);
Ollama, if it is missing (winget on Windows, Homebrew on macOS, the official script on Linux);
readscout itself;
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@readscoutThe 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 setupThat 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 doctorRestart Claude Code / Codex.
First steps
Check the setup:
readscout doctormust end withAll good.(plugin users: use theuvx ... readscoutform above).Open any project in Claude Code or Codex.
Ask something that needs a lot of reading, in your own words. For example:
"Which API routes in
src/routesdon'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).
Watch the agent call
local_askorlocal_digestand get a short receipt instead of opening every file. The first call loads the model into memory (10-30 s); later calls are faster.See what it saved:
readscout stats, orreadscout dashboardfor 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.logEveryday 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 withreadscout pull <model>for better answers;The list may be incomplete: the agent should narrow the question or add agrep;
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 benchmarkSettings 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 |
|
|
6-7 GB VRAM |
|
|
8-9 GB VRAM, 16 GB RAM |
|
|
10 GB VRAM or more, 8 GB RAM or more, less than ~30 GB RAM |
|
|
6-14 GB VRAM, 32 GB RAM or more |
|
|
15 GB VRAM or more, 16 GB RAM or more |
|
|
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) | |
| 554-566 tokens/s | 1,008-1,205 tokens/s ( |
| 42-45 tokens/s | 24-25 tokens/s |
| 181 s | 127 s |
| 30 s | 54 s |
| 0.93, 23 s/task, edits 9.7 s | 0.94, 23 s/task, edits 14 s |
| 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 |
| 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 machineOnly 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 |
|
"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 ( |
llama.cpp is slower than Ollama on an NVIDIA GPU |
|
llama.cpp split the model onto your integrated GPU |
|
"Model ... is not installed yet" |
|
A model fails to load with "out of memory" or "Gemma4Assistant requires ctx_other" although the GPU looks free | a |
The agent never uses readscout | restart the agent after installing; check with |
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.1only; 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 startsllama-serveritself, bound to127.0.0.1on a free port with a random secret key (so a web page cannot query it), only for the.gguffiles you configured; a server you run yourself must be on127.0.0.1too.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,Authorizationheaders,password/secret/tokenassignments, also in JSON) are masked before reaching the model, andlocal_editrefuses 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,
Readlimited to some folders in Claude Code's permissions), readscout does not see those rules: it reads what the agent names and runs itsgatecommands. To keep the same limits, usereadscout folders add <folder>(the local models then only read and write inside the listed folders;readscout foldersshows the list,readscout folders remove <folder>drops one) andreadscout gate off(local_editthen refuses any gate command).readscout doctorshows 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_editwrites atomically, never overwrites a file that changed while the model was working, and restores only what it wrote. Itsgatecommands 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.jsonandmetrics.jsonl(tool, model, sizes, timings and counts; never file contents, questions or answers), and with llama.cppllamacpp.json(the running server's process, port and last use) andllama-server.log(model loading messages and timings; no file contents). Nothing is sent anywhere. Agent installers back up~/.codex/config.tomlonce (config.toml.readscout-bak) and only touch themcp_servers.readscoutentry.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 publishesSHA256SUMSfor 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 readscoutModels 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
Available Tools
3 toolslocal_askARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | find | |
| paths | Yes | ||
| quality | No | ||
| question | Yes | ||
| max_items | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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_digestARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| focus | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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_editADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| gate | No | ||
| paths | Yes | ||
| instruction | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
3 tool updates
v0.1.0- First observed
local_ask - First observed
local_digest - First observed
local_edit
TDQS
Scored across 3 tools
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.
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.
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.
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
Related MCP Connectors
Shared memory for coding agents. Stop re-explaining your codebase every session.
Token-efficient search for coding agents over public and private documentation.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to search and ask questions about a local codebase with citations, using BM25 and optional embeddings, all offline.4 npm1MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI coding agents to retrieve only the specific code sections that answer their questions, drastically reducing context usage while running fully locally.1MIT
- FlicenseNot gradedqualityBmaintenanceEnables 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.-
- AlicenseNot gradedqualityBmaintenanceEnables 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 PyPI4MIT