Skip to main content
Glama
gorillanobakaa-dot

Fieldkit

by gorillanobakaa-dot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Fieldkit

Tested tools that let a small AI model on your own laptop do real work: find code, check and clean documents, run builds, and refuse to publish anything it cannot prove.

Built for the people every other tool prices out: kids with no credit card, 15-year-old laptops, data sold by the megabyte. Free forever, by design, not as a trial. Why, with the numbers: PHILOSOPHY.md

tests

The model is a small part of the job. The tools around it decide whether the job gets done. Fieldkit is those tools: deterministic Python that does the same thing every time, checks its own result, and answers in plain JSON. The model only has to choose the right tool.

Measured on one ordinary laptop (Intel i7-1255U, LM Studio): the same small model, Gemma, got one of five tasks right with basic tools and five of five with Fieldkit, in about half the time and with fewer tokens. Five tasks is a small test; run it on your own model with fieldkit exam.

What it does (Layman Track)

Start here if you have never opened a terminal. This section explains every part of Fieldkit in plain words: what it does for you, how it works step by step, what it touches on your computer, and what it cannot do. Each part ends with two links: a full plain-language guide, and the technical guide for people who want to check the work.

The idea in one paragraph

You run an AI helper on your own computer, and it is usually a small model. Left alone, a small model guesses: it opens file after file, loses track, and sometimes makes things up. Fieldkit is a box of tools that do the hard part, check their own result and hand back a plain answer, so the model only has to pick the right tool. Everything runs on your own machine. There is no account, nothing is sent anywhere, and it costs nothing.

How you use it

There are two ways, and they reach the same tools.

  1. You type a command. On Windows, press the Windows key, type PowerShell and press Enter. Then type a command such as fieldkit host and press Enter. It answers in plain words.

  2. Your AI helper uses it for you, through the "agent door" described in part 1. You stay in charge: anything risky waits for you.

Installing it on a computer without git (an old Mac, a small Linux box)

You do not need git, Homebrew, Xcode or an administrator password. In a terminal:

curl -fLO https://raw.githubusercontent.com/gorillanobakaa-dot/Gorilla.Fieldkit/main/install.sh
sh install.sh

It asks before each download or install, puts everything in one folder (Fieldkit), and at the end writes Fieldkit/INSTALLED.txt: what it downloaded and installed, and how to remove it (delete the folder). No curl? Download the zip from GitHub in your browser, unzip it, and run sh install.sh inside the unzipped folder. On a computer with less than 8 GB of memory or no compiler it installs only the two small packages the core needs; the others come when a tool that needs them is wanted. First tried on a 2011 MacBook Air (macOS 10.13, 4 GB) on 2026-10-23.

Every command ends with a fixed number that programs can read: 0 all fine, 1 something broke, 2 the command was typed wrongly, 3 it found problems you should look at. Add --json to any command for an answer a program can read.

1. The agent door: how an AI is allowed to touch your computer

Think of a reception desk. The AI never walks into the building; it asks at the desk.

  1. The AI describes the job in plain words, for example fieldkit agent discover word file safe to send, and gets back the tools that fit.

  2. Every tool has a card: what it needs, what it changes, and how risky it is: read-only, reversible or irreversible.

  3. A tool nobody has reviewed is refused, with the reason.

  4. What the AI asks for is checked against the card before anything runs.

  5. A tool that changes files shows a preview first. When it runs for real, Fieldkit backs up the files, runs the tool, checks the result, and puts the backup back by itself if the check fails. It keeps a record so fieldkit agent undo RUN can reverse it later.

  6. Anything that changes your system (registry, services, power, hardware) or cannot be undone waits for you to type --approve. AI programs reach Fieldkit through MCP, the standard link for AI tools, and that link has no way to approve.

What it touches: only the files and folders a card names, plus its backups and records in the state folder. undo checks its own record before trusting it, like a cloakroom attendant who checks the ticket number and the coat: it puts back only files inside that run's own backup and scope, and refuses if you edited a file after the run (you can overrule that at the keyboard with --approve; an AI cannot). What it cannot do: it is not a sandbox: a tool still does what its own code does. fieldkit agent run applies the change unless you add --mode preview.

Guides: plain language · technical

2. The engine: long jobs, privacy checks and before/after pictures

  • Long jobs in stages. A job such as a build is a list of numbered stages. A stage counts as finished only when its checks pass (a file exists, the output says what it should), never just because the program said it finished. If the job stops, it resumes where it stopped. fieldkit next NAME tells you the one next thing to do: DO, BLOCKED, CANNOT HERE or DONE.

  • Privacy scan. fieldkit privacy scan FOLDER looks for passwords and keys, home-folder paths, email addresses and your own private words before you publish anything. You list your private words in fieldkit.local.json, so they are never written into the code.

  • Before and after. fieldkit snapshot take before, do something, fieldkit snapshot take after, then fieldkit snapshot diff before after shows exactly what changed: files, services, scheduled tasks and installed programs.

  • Stopping programs safely. Fieldkit remembers the programs it started and stops only those, never a program of the same name that you are running.

What it cannot do: the privacy scan only finds patterns it knows and words you listed. A file it cannot read, or one over 5,000,000 bytes, is reported as "not scanned", which counts as a problem, never as clean. A pipeline file can run any program, so run only pipelines you trust. The Linux side of snapshots and of stopping programs has only been tested on Windows so far.

Guides: plain language · technical

3. The tool collection: knowing which scripts can be trusted

  1. fieldkit gather copies scripts from the GitHub projects and folders listed in imports.yaml into one toolbox folder, and records where every file came from with a fingerprint, so it can tell you later if a copy has changed.

  2. fieldkit harvest reads every script without running it and writes a one-line index of what each does and what it touches. fieldkit harvest --find WORDS searches it in plain words.

  3. fieldkit cards list and fieldkit readiness give each tool a trust level: gathered (only copied in), carded (reviewed), tested (its tests passed on this exact file) and verified. An AI may only start tools that have been reviewed.

What it cannot do: the "safe to start with --help" check reads the script's structure without running it and treats any real work at the top of the file as unsafe; it can still miss work hidden behind an unusual trick. fieldkit gather --check never touches the network, and a failed update is reported as an error instead of quietly keeping the old copy. Draft cards stay at gathered, so an AI must not run them unreviewed.

Guides: plain language · technical

4. Office documents: read, make, check, clean, send

You want to

Type

Read a Word, Excel, PowerPoint or PDF file as plain text

fieldkit office read FILE

Make a new one from a short description

fieldkit office create SPEC OUT

Check the file is not broken

fieldkit office check FILE

Remove people's names from its hidden properties, comments and tracked changes

fieldkit office scrub FILE

All of that, then a privacy search: is it safe to send?

fieldkit office deliver FILE

Check a CV, hear what is missing, and get a UK-style CV in English and Romanian

fieldkit cv check FILE, fieldkit cv render

Find UK jobs on official job sites, score them, and prepare each application (you press Submit)

fieldkit jobs run

A student: when is it due, is every source cited and listed, is it all in the right language, what do I do next

fieldkit academic next FOLDER

A research run: did it open what it cites, and does each page say what the claim says?

fieldkit evidence check FINDINGS.md --store

Which free sources cover sanctions, migration, genomics...? Search scholarly and data APIs without a key

fieldkit evidence sources find WORDS, fieldkit evidence search SOURCE QUERY

Tell the other AI session on this laptop something, or wait until it has finished

fieldkit peers list, fieldkit peers send NAME "text", fieldkit peers wait --notify-when-idle NAME

Back up the whole kit into your backup folder, and prove the copy is good

fieldkit backup

Copy that backup to a USB stick and prove it there; nothing on the stick is ever deleted or overwritten

fieldkit backup usb

A student before submitting: every check in order, one verdict, the first thing to fix

fieldkit academic check FOLDER DRAFT

A student with no AI to hand: a numbered menu, in English or Romanian, from a desktop shortcut

fieldkit academic menu

Blurry desktop icons: find out why and fix them with one click (Windows, and GTK/KDE on Linux)

fieldkit icons cache --apply, fieldkit icons install-fix-button

deliver answers SAFE TO SEND or NOT SAFE, with the reason. Nothing is uploaded.

Backups of cleaned files go into Fieldkit's own state folder, never next to your document, so sharing the folder cannot leak the names that were removed. deliver says NOT SAFE if an old backup or a Word lock file sits beside the document.

What it cannot do: it cannot clean the Author and similar properties inside a PDF; it finds them and says NOT SAFE, so you re-export the PDF with those fields empty. Parts it cannot read or decode are reported as "not scanned", which also means NOT SAFE. create refuses to replace an existing file unless you add --force.

Guides: plain language · technical

5. Builds, releases and the laptop's temperature

  • Why did the build fail? fieldkit triage LOG reads a failed build log and names the known cause and fix, or says plainly that this failure is new.

  • Does everything it names exist? fieldkit refcheck checks every file, link and module a project names really exists.

  • Is this release true? fieldkit release check refuses to call a release safe to publish unless the published files match the tested ones and every claim in the release notes has a passing proof. There is no way to force it.

  • Install, test, remove. fieldkit lifecycle SPEC --approve installs a program, checks it, uninstalls it, and lists anything left behind.

  • Debian kernels. fieldkit kernel helps build a custom Debian kernel step by step. On 2026-10-11 its build, RPM and reproduction stages ran for real on Linux 7.2.9 with a small configuration; a build with the full kernel.config has not run in this setup.

  • Is the binary the same when someone else builds it? fieldkit repro compare A B checks two builds byte for byte. When they differ, it names the file (inside .deb, tar and zip archives too) and the cause: a build folder, a date, a file order, a Windows link time. The Go pipelines build every binary a second time in another folder and stop if the bytes differ (Gorilla OpenCode: both binaries identical). The kernel pipeline does the same for its packages, and fieldkit build-harness repro TASK --run does it for the Firefox build.

  • Temperature. On 2026-10-02 the build laptop switched itself off in the middle of a compile. The build had been trusting a temperature sensor that was stuck at 41.85 C for 386 readings while the processor heated up. Now Fieldkit trusts a sensor only after watching it rise under full load (fieldkit thermal prove). During a long build it lowers the processor's top speed to keep the laptop under the limit (fieldkit thermal watch).

What it cannot do: thermal watch changes your power plan's maximum processor setting while it runs and puts it back when it stops, also when you press Ctrl+C; if the laptop loses power mid-run, check the setting in Power Options. It only understands English powercfg output. The kernel download's signature is not checked yet.

Guides: plain language · technical

6. The exam: measure your own model

fieldkit exam run --model ID builds the same small invented project every time and gives your model five jobs: find a function, spot a name that does not exist, explain a failed build log, find a block of code, and list missing files. It runs each job once with basic tools and once with Fieldkit. A fixed script marks each answer; no AI judges another. fieldkit exam report shows the table. The same small model, Gemma, got 1 of 5 right with basic tools and 5 of 5 with Fieldkit.

What it cannot do: five jobs is a small test, and the same author wrote the jobs and the tools. The tools were improved after watching Gemma fail these jobs, so 5 of 5 shows the effect; it does not prove your model will do every real job.

Guides: plain language · technical

7 to 10. The Gorilla Firefox build harness

The last four parts carry the Gorilla Firefox privacy changes onto each new Firefox release, build it, install it, and prove it does not talk to anyone it should not. They were built for that browser, but the lesson applies to any big build: a build that finished is not a browser that works, and a browser that works is not a browser that keeps your secrets. Each step must be proven.

What this whole machine is, why it exists, who else does similar work and how much it does, with the numbers: The build harness, explained.

7. Porting a new Firefox release

  1. Fieldkit fetches the untouched source of the latest stable Firefox from Mozilla's own release tag and keeps a read-only copy (the vault).

  2. It makes a working copy and applies every Gorilla change that still fits, with no guessing.

  3. Every change that no longer fits becomes one small, checked job. Fieldkit tries it itself first, carrying wording files, key files and settings across by name.

  4. Only the leftovers go to the small local model. The model answers in text; Fieldkit makes the edit and checks the file.

  5. Anything that needs human judgement is parked for the maintainer with a written explanation.

  6. The maintainer's own fixes are recorded (fieldkit build-harness record) and exported as patches (fieldkit build-harness export-hand), so the next Firefox release starts from them. For Firefox 157 that was 20 patches: 3 port fixes and 17 privacy cuts. Applied in order, they rebuild the exact same source tree.

What it cannot do: a failed model attempt resets the working copy, so an edit that was not recorded is lost. Kernel porting is not available. Each recorded edit says whether it is a privacy cut or a port fix; an older edit without that label is sorted by keywords, and the export prints each patch's kind and how it was decided, so read the list before publishing it.

Guides: plain language · technical

8. Checking the source and building it

In Firefox 157 a half-removed piece of code left one file that could not be read. The build still finished, and the browser's address bar did nothing. So before compiling, Fieldkit reads the files themselves, not the work record:

  1. Every changed JavaScript file must parse.

  2. Every name a file imports must still exist in the file it comes from.

  3. No build list may be left empty.

  4. Every change must be explained by the previous release or by a recorded step (truthbound).

  5. Three known kinds of breakage are fixed by repair itself. Each fix is proven, and the file is put back if the proof fails.

Then build-run waits for an idle processor, proves a temperature sensor, and runs the build under the temperature guard. It recognises known stops (a broken object file, a missing tool, a full disk, an interrupted console, an empty build list and others), fixes them and retries. A stop it does not know is written down with its first errors, so a fixer can be added and the next one fixes itself. When an AI does the work, its result is judged from the files on disk, not from its report.

A repair is proven with Node.js; if Node.js is missing, the repair counts as failed and the file is put back. A fix that names a file outside the working copy is refused.

What it cannot do: several paths are set for the maintainer's own machine. The session watcher has no tests yet.

Guides: plain language · technical

9. Installing the browser and proving it works

  1. Backup. The installed browser and your profiles are zipped into Documents\Gorilla.Firefox.Backups, with a fingerprint list.

  2. Install from the fingerprinted zip, not the installer: the installer once reported success after installing nothing.

  3. Clear old cached scripts. Four builds once shared one build number, and a profile kept running a broken build's cached scripts. Now the build number changes with the source, and every install clears the caches.

  4. Prove it on the browser you actually run (fieldkit build-harness post-install TASK): the settings are in force, the removed AI parts are really gone, it starts cleanly, its own web log shows no Mozilla addresses, ads are blocked on a real news page, and a web page cannot see your local network address. Build 11 asked 0 Mozilla or Firefox addresses over 75 seconds on a real page and reached 0 of 16 ad and tracker domains.

  5. The address-bar test takes your keyboard. It runs only with --drive, after a 20-second countdown. Save your work and stop typing when you see the warning.

  6. The way back: fieldkit build-harness install TASK --restore BACKUP_FOLDER.

It only installs over a program that is clearly Gorilla: an entry that only says "Firefox" is never picked, and if it finds none or several it stops and asks for --install-dir. --restore puts back the browser and your profiles; your current profiles are moved aside, never deleted. A check that was skipped is shown as SKIPPED, and the verdict is OK only when every check ran and passed. Throwaway test profiles are deleted after each check; the logs are kept as evidence.

What it cannot do: it cannot prove a website works the way you expect; it proves the settings, the removed parts, a clean start, the web addresses the browser asks for on its own, ad blocking and local-address hiding.

Guides: plain language · technical

10. The leak gate: no release until every connection is proven

This is the last checkpoint before a build is published. It answers PASS or FAIL.

  • It fails closed. Anything the browser does that is not on the approved list is a failure. An entry nobody approved is a failure. A check that collected no evidence is a failure, never a pass. PASS needs all 18 rules to pass.

  • It uses many witnesses, not one. Up to seven watch at once: the browser's own logs, a decrypting proxy, the table of open connections, the list of running programs, the files on disk, a packet capture, and a test name server that logs every name looked up. One witness can be fooled; seven that must agree are much harder to fool.

  • It plays 13 scenes: starting and idling, the new tab, the home page, the add-ons and settings pages, secret "canary" words in normal and private windows, background workers, WebRTC, bad certificates, a crash, deliberately broken server answers, a real web page, and a normal close.

  • Only the maintainer approves. A model may propose an entry for the list; approving it needs the maintainer at a real keyboard.

  • It reads the code too. 103 source files that can reach the network, in 25 parts of Firefox, each have a written decision; one (OCSP, certificate checking) is still the maintainer's call. It also checks the packed files, the programs' network libraries and the Rust libraries against the previous release.

  • Quick and release runs. A quick run helps while fixing and can never pass. Only a release run in an administrator window, three times over with packet capture, counts.

The first baseline. The regression rule compares a new build with the last approved one. For the very first release there is nothing to compare with, so the maintainer, at the keyboard, may save the first baseline from a release run whose only failure is that missing baseline; every other rule must have passed. The next release run must then pass in full before anything is published.

What it cannot do: the Linux runner, meant to be the final referee, has never been run on Linux. On Windows the packet capture records every program's traffic, not only the browser's.

Guides: plain language · technical

What Fieldkit will never do

  • Approve something on your behalf, or let an AI approve it.

  • Count a check that did not run as a pass.

  • Send your files anywhere. It uses the network only when you ask: to fetch tools (gather), to talk to the model server on your own computer (exam), or to open the leak gate's test pages.

Related MCP server: a0

Technical Definition (Developer Track)

Python 3.11+, one codebase for Windows 11 and Debian, AGPL-3.0-or-later. Every command takes --json; exit codes are fixed: 0 fine, 1 error, 2 bad usage, 3 findings.

  • Agent interface. discover, describe, run, undo, served on the command line and over MCP (fieldkit mcp, JSON-RPC 2.0 on stdio). run enforces one sequence: refuse draft cards, validate inputs, preview, require approval where the card says so, back up the scope, apply, verify, restore on failure. The MCP surface has no approval argument.

  • Tool cards. Each tool declares inputs (read from argparse by AST, never by running it), effects, safety (read-only, reversible, irreversible), modes (preview, apply, undo, verify) and tests. Trust ladder: gathered, carded, tested (a pass recorded on the file's current sha256), verified.

  • Pipelines. YAML stages with fingerprinted, resumable state and verify checks (files_exist, file_contains, output_contains, output_lacks, python). A stage is done only when its checks pass, never on exit code alone.

  • Release gate. release check exports the tag with git archive, runs its tests there, compares published files by sha256, privacy-scans, and demands a passing proof for every claim in the notes. release prove records evidence from another machine (platform, git tree id, result). No --force.

  • Tests. python -m pytest. On the author's Windows 11 laptop (2026-10-02): 809 passed, 1 skipped, 1 known fault kept as a strict xfail. GitHub Actions runs them on Windows and Ubuntu on every push (see the badge). A skipped test names the tool it needs.

  • Documentation. fieldkit docs (Gorilla.Documentation.IBM.Style): every module group has a layman and a developer track built with DualTrackAgent and the writer brief (fieldkit/gdocs/WRITER_BRIEF.md), and fieldkit docs check --strict fails when a track is stale, thin, unsafe or quotes a number nobody measured. Index: docs/dual-track.

Release notes: GitHub releases.

Table of contents

  1. Install

  2. Connect it to your AI helper

  3. What is in the box

  4. How it keeps changes safe

  5. Your own tools stay private

  6. Measure it on your own model

  7. The release gate

  8. Honest limits

  9. Layout

1. Install

Step-by-step guide, for people and for developers: INSTALL.md. It shows how to ask your AI to install Fieldkit or do it yourself, where to put it, how to connect it to Gorilla OpenCode and LM Studio, and how to make a small model aware of it.

The short version (Python 3.11 or newer and Git):

git clone https://github.com/gorillanobakaa-dot/Gorilla.Fieldkit
cd Gorilla.Fieldkit
python -m pip install -e ".[test]"
python -m pytest -q
fieldkit host

  • Pass: the tests end with zero failed. Some say skipped and name a tool: those need fieldkit gather first (section 3).

  • Pass: fieldkit host prints your system and Python version.

  • If fieldkit is not recognised: use python -m fieldkit instead. It does the same.

To remove it: python -m pip uninstall fieldkit, then delete the folder. Fieldkit changes nothing else on your computer.

2. Connect it to your AI helper

Full steps, backups and checks: INSTALL.md, steps 4 to 6.

Fieldkit speaks MCP, the standard way AI helpers use outside tools. Your helper then sees nine tools: discover, describe, run, undo, next and readiness, plus the three the build harness gives a model (build_harness_status, build_harness_next, build_harness_submit: one small job at a time, and the harness checks the result; approving and skipping are not among them).

Gorilla OpenCode - add to your config.json (on Windows, %USERPROFILE%\.config\gorilla-opencode\config.json), then restart it:

"mcpServers": {
  "fieldkit": { "type": "stdio", "command": "fieldkit", "args": ["mcp"], "trust": "local" }
}

"trust": "local" (Gorilla OpenCode with local-server trust) lets Fieldkit say, per answer, whether it carries text someone else wrote and whether it went online. Your own checks then run without the "untrusted content" question after every step; reading a downloaded document still asks. Tools that go online run only when the call says network=true. Leave trust out to have every call treated as a stranger's.

Claude Code:

claude mcp add fieldkit -- fieldkit mcp

LM Studio (versions with MCP support) - add the same fieldkit entry to its mcp.json.

If your helper cannot find the fieldkit command, give the full path to it instead, for example the fieldkit.exe in your Python Scripts folder.

  • Pass: the first time the AI uses Fieldkit, your helper asks you to allow it.

3. What is in the box

Job

Command

Read a Word, Excel, PowerPoint or PDF file as text

fieldkit office read FILE

Create one from a JSON or YAML description

fieldkit office create SPEC OUT

Check it is not broken

fieldkit office check FILE

Remove people's names from its hidden properties

fieldkit office scrub FILE

All of the above, safe to send?

fieldkit office deliver FILE

A CV against fixed rules (general + trade), the questions to ask; UK CVs from a profile, EN/RO, .docx + .pdf

fieldkit cv check FILE / fieldkit cv render --variant V --lang ro

UK job hunt: Reed and Adzuna APIs only, scoring, packs, letters of approved sentences only, tracking; never submits

fieldkit jobs run --top 8 (skill: fieldkit-career)

Academic work in 7 countries (uk, us, es, pt, it, de, ro): the deadline and upload date asked, citations <-> references, APA 7 / Harvard / ISO 690 shape, work-language and spelling check, words, plagiarism pre-check, the one next step; finished Word documents, slides and posters, and templates for 32 document types, in the country's layout and the work language

fieldkit academic (skill: fieldkit-academic)

Research evidence: pages fetched safely (no private addresses, robots.txt obeyed, paced, honest User-Agent) into a store kept by hash with their words; a run's findings imported as one record per claim; every claim checked against the output contract, the run's own fetches, its snapshot and its quote

fieldkit evidence (skill: fieldkit-evidence)

A laptop on a TV by HDMI: is it connected, what is wrong, and connect it now - restarting a stuck GPU driver (TV seen, 0 modes) when that is what it needs, with Windows' own consent prompt

fieldkit hdmi status, fieldkit hdmi fix

Windows 11, made lighter on any PC: the tweaks framework's ten modules with a preview and an undo each, elevated runs waited for, and fit - which service-profile entries (measured on a ThinkPad) would be wrong on this PC

fieldkit win11 (skill: fieldkit-win11)

Sessions that talk: list the AI sessions on this computer, send one a note ("I am about to restart the build"), wait for a reply or for "my turn is done". Gorilla OpenCode's own protocol, so an OpenCode session hears it; same account only, no network; what arrives is fenced as text from another program, never as an order

fieldkit peers

A dated, verified zip of the harness into the backup folder (never guessed)

fieldkit backup --to FOLDER

A status report a reader with ADHD, dyslexia or autism can take in pieces: one line, then what is asked of them, then the rest; seven headings in six languages; sentences, asks, idioms, abbreviations and italics checked against written rules; the report is a file you fill in, no model involved

fieldkit sitrep template / check / render FILE (skill: fieldkit-sitrep)

A teaching log from a session transcript: every shell command an AI session ran, in order, with what came back and whether it failed; the session's own words left out, so a job done once becomes a record the harness can be taught from

fieldkit teach [SESSION] --out LOG.md; fieldkit teach propose LOG.md --out DIR turns a log into a pipeline draft, signature stubs and card candidates, every unknown marked TO FILL

A terminal window opened in front of a person who does not know where the terminal is, with the command printed and ready: ask waits for their Enter (closing the window is a refusal), run runs at once; the window is the desktop's own and outlives the session; everything printed goes to a log

fieldkit terminal ask -- /full/path/to/program ...

A laptop's everyday repairs, from the academic harness, for any laptop: the processor locked slow by the firmware (measured, unlocked, proven; a logon guard on Windows), a voice when an AI assistant finished or waits for an approval (Claude Code hooks, Antigravity's transcripts), low sound on Windows (diagnose, the safe fix and its undo, the driver listed for the exact chip), the master volume, the NVIDIA Control Panel app, the wallpaper, identical AI rule files

fieldkit laptop cpu / alerts / sound / volume / video / wallpaper / rules

Everyday cooling on Windows: a profile (quiet, balanced, performance, off), a monitor that lowers the processor cap when hot and says so, started at login; HWiNFO's readings as a proven sensor

fieldkit thermal profile / monitor / autostart

The newest backup copied to a USB stick and read back (SHA-256, every CRC); a reminder when the last copy is old. Nothing already on the stick is deleted, moved or overwritten; a full stick stops the copy

fieldkit backup usb, fieldkit backup remind

The academic harness's remaining parts, for any student: the whole pre-submission check with one verdict (check), reading the brief (brief, date), the marks and what markers say (record), assignments copied out of OneDrive (local), a self-test that builds real files (preflight), the numbered menu and its desktop shortcut (menu, shortcut); guides in English, Spanish, Portuguese, Italian, German and Romanian

fieldkit academic check / brief / record / local / preflight / menu

IconKit: why icons are soft (icon cache vs. the file), cache rebuild with backup, .ico frame reader and crisp gates, recoloured icons from one master

fieldkit icons --help (skill: fieldkit-icons)

Find secrets, home paths, emails, your private words

fieldkit privacy scan PATH [--git]

Name the cause of a failed build

fieldkit triage LOG

Run a staged, resumable build

fieldkit pipeline run NAME

The one next thing to do in a pipeline

fieldkit next NAME

Every named file, link or module must exist

fieldkit refcheck ...

Record state, then prove what changed

fieldkit snapshot take / diff

Install, check, uninstall; list leftovers

fieldkit lifecycle SPEC --approve

Prove a release before publishing it

fieldkit release check / prove

Find a tool by describing the job

fieldkit agent discover WORDS

Index what every script in a folder does

fieldkit harvest --find WORDS

Bring in tools from GitHub, with their tests

fieldkit gather [--test]

Measure a model with and without the kit

fieldkit exam run --model ID

Is the temperature sensor real? Keep a build cool

fieldkit thermal prove / watch

Port, build, install and prove Gorilla Firefox

fieldkit build-harness ... (part 7 to 10 above)

Release gate for leaks and telemetry

fieldkit build-harness leakgate TASK --release

Open every about: page of the installed build and judge it (text, artwork, errors, missing strings, requests); walk=1 clicks every about:about link in a visible window, live

fieldkit build-harness about-pages TASK [walk=1]

Every about: page the source can register (tree and upstream), what the last build registered, and the owner's verdict from decisions/ABOUT-PAGES.yaml; the register is enforced before the build (D-157-40) and after it (about-pages)

fieldkit build-harness about-registry TASK

Every hidden about: page explained, with its picture: English (both tracks, published) and Romanian, rendered from one source and checked against the research (also in release-check)

fieldkit build-harness hidden-pages-doc TASK [write=1]

The release page tells everything since the last release: every decision named, under GitHub's 125,000-character limit, the hidden pages on the page itself

fieldkit build-harness release-cover TASK page=FILE (and hidden-pages-doc TASK release=FILE for the hidden pages' release edition)

What a change costs or saves in RAM and CPU, page by page

fieldkit build-harness weigh TASK

Run a long build-harness command like screen: its own visible window, started by Windows, survives the session, logged, and the machine kept from idle-sleeping until it ends

fieldkit build-harness window build-run TASK

Keep the machine from idle-sleeping until a run already going ends

fieldkit build-harness awake PID

Satellite mode judged: identity and scripts per level and per kind of site, call sites included (also after every build and install)

fieldkit build-harness satellite TASK

Help > About carries the build stamp; build-verify and post-install hold it to the build that was made

buildstamp.py (rows in build-verify and post-install stamp)

Write or check the dual-track documentation

fieldkit docs plan / prep / render / check

Learn how to write for a reader who has never opened a terminal

fieldkit docs guide

Read why: the Gorilla Open Source Philosophy

fieldkit docs philosophy

Build a release page with both documents on it, plain language first

fieldkit release-page compose

Check a release page before publishing it

fieldkit release-page check PAGE

Pipelines that ship: office-deliver, firefox-windows (drives the Gorilla Firefox build harness) and debian-kernel. Triage knows Firefox on Windows, the Debian kernel and Debian packaging failures. New failures are added as data, in fieldkit/build/signatures/.

fieldkit gather copies these repositories into toolbox/ and records the commit and sha256 of every file: pfind, searchfox-tools, model-eval, code-review-toolkit, dual-track-doc-generator, debian-kernel, sensors-gorilla, speaker-loudness-fix, black-gorilla-theme, apple-superdrive-enabler, respect-your-llms and the HDMI harness. fieldkit gather --test runs each one's own tests.

4. How it keeps changes safe

Every tool has a card that says what it changes. When the AI asks to run one:

  1. Read-only tools run straight away.

  2. Tools that change files show a preview first. When applied, Fieldkit backs up the files, runs the tool, checks the result, and puts the backup back if the check fails. undo restores them later.

  3. Tools that change the system (registry, services, power, hardware) or cannot be undone wait for your approval. Over MCP there is no way for the AI to give it.

The process runner records the programs it starts and stops only those, never a program of the same name that you are running yourself.

5. Your own tools stay private

Put your own tools in a local/ folder next to the code. Git ignores it, and Fieldkit merges it in when it loads:

File

What goes in it

local/tools.yaml

Cards for your own scripts (same format as fieldkit/desk/tools.yaml)

local/imports.yaml

Your own folders for fieldkit gather

local/tests/

Tests for your own scripts; pytest runs them with the rest

fieldkit.local.json

Machine paths and your private words for the privacy scan

Copy fieldkit.local.example.json to fieldkit.local.json to start. Your name and email go in its privacy.terms list, so the scan finds them without them ever being written in code.

6. Measure it on your own model

fieldkit exam builds the same small test project every time and gives your model five tasks, once with basic tools and once with Fieldkit. It talks to an OpenAI-compatible server on your own computer (LM Studio's address by default).

fieldkit exam run --model <model id as your server lists it>
fieldkit exam report

The result on the author's laptop:

Model

Basic tools

With Fieldkit

Gemma

1 of 5, 762 s, 8,349 tokens

5 of 5, 410 s, 6,630 tokens

Qwen3 30B-A3B

3 of 5, 1,415 s, 60,379 tokens

5 of 5, 1,030 s, 34,455 tokens

Five tasks on one test project, written by the same author as the tools. It shows the effect; it does not prove it for every job.

7. The release gate

A release spec in releases/ lists the tag, its tests, the files that must match what was tested, and the claims the release notes may make, each with a proof.

fieldkit release check releases/<name>.yaml    CLEAR, or DO NOT PUBLISH with every reason
fieldkit release prove releases/<name>.yaml    run the tag's tests on THIS machine; record evidence

A claim such as "runs on Windows and Linux" passes only with a passing prove from each platform for the same code. There is no --force: a failing gate means you fix the release or fix the check.

8. Honest limits

  • The Debian kernel pipeline has run for real only with a small configuration (2026-10-11), not yet with the full kernel.config.

  • The Firefox package has not been reproduced yet: build-harness repro needs a second full build on the build machine.

  • The firefox-windows pipeline needs the Gorilla Firefox build harness.

  • The privacy scan finds patterns and the words you list. It cannot know a secret it has no pattern for.

  • Fieldkit reads commands and files. It is not a sandbox.

  • Office text extraction handles ordinary documents; for complex layouts, install the optional [readers] extra (markitdown, docling).

  • Known faults are kept as tests marked "expected to fail", so a fix is noticed.

9. Layout

fieldkit/core     host, settings, process runner, privacy, pipeline engine, next, snapshot
fieldkit/office   read, create, check, scrub, deliver
fieldkit/build    triage + signatures, kernel, refcheck, lifecycle, pipelines
fieldkit/desk     registry (tools.yaml), cards, discover, readiness
fieldkit/exam     fixture, tasks and graders, toolsets, runner
fieldkit/thermal  proven temperature sensors, the build governor
fieldkit/buildh   Gorilla Firefox build harness: port, verify, repair, build-run, install, proof
fieldkit/leakgate the fail-closed leak and telemetry release gate
fieldkit/gdocs    Gorilla.Documentation.IBM.Style: fieldkit docs plan/prep/fill/render/check/index/guide
docs/             groups.yaml, dual-track/<group>/ layman and developer tracks, MEASUREMENTS.md
fieldkit/agent.py, mcp.py, release.py, gather.py, harvest.py
skills/           short SKILL.md pointers; install_skills.py puts them where agents look
tests/            python -m pytest
AGENTS.md         instructions for AI agents working on this code

Licence: AGPL-3.0-or-later. If you run a changed version as a service, its source must stay open too.

Available Tools

10 tools
build_harness_briefsA
Read-only

Read-only. The decisions waiting for the person, each as a full brief (what is affected, verbatim; every option and its cost; the recommendation). Show the brief instead of asking a question. Optional id: one brief in full. You cannot record an answer: only the person can, at a terminal.

NameRequiredDescriptionDefault
idNo

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover readOnlyHint and destructiveHint, so 'Read-only' is redundant, but the description adds a non-obvious constraint the annotations cannot express: the agent cannot record an answer because only the person can, at a terminal. That directly shapes what the agent should do after retrieving a brief and goes beyond structured data.

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?

Four short, front-loaded sentences with no filler; the list/single-id behavior and the terminal-only answer constraint both appear early. The only waste is the leading 'Read-only', which restates an annotation already declared.

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, and the description compensates by describing the brief's contents (what is affected verbatim, every option and cost, the recommendation), so an agent knows what it will get back. Combined with the id behavior and the no-answer constraint, nothing critical is missing for a one-parameter read tool.

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 coverage is 0% — the lone 'id' property has no description at all — so the description must carry the meaning. 'Optional id: one brief in full' successfully explains both the optionality and the effect of supplying it (narrowing from the list to a single complete brief), which is otherwise unknowable from the schema.

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 concrete resource — the decisions waiting for a person — and specifies it returns each as a full brief with a defined structure. The verb is implied by the framing ('show the brief') rather than a clean verb+resource pair, but an agent can tell this lists/renders decision briefs rather than acting on them.

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?

'Show the brief instead of asking a question' is a real usage instruction for the agent's conversational behavior, which is useful. However, it never contrasts with the closest siblings (build_harness_next, build_harness_status) or states when to request the full list versus a single id, so guidance is implied rather than explicit.

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

build_harness_nextB
Destructive

Your ONE next job in the build: what to do, the only files you may change, the text you need, and how it will be checked. Do only this job.

NameRequiredDescriptionDefault

No parameters

TDQS

B3.3/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=true, so the agent already knows this is a mutating operation. The description adds useful context about the shape of the returned job and the strict scope limit on file changes, but it never discloses how the tool itself is destructive — whether calling it consumes or advances the build plan, or whether it is idempotent. For a destructive operation that is a meaningful omission.

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 short sentences, front-loaded with the core purpose. The 'ONE' emphasis and the closing imperative are efficient; no filler text.

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?

There is no output schema, so the description must describe the return value and it does so at a high level, which is adequate. But for a destructive, zero-parameter state-advancing tool, it is missing sequencing rules, repeat-call behavior, and how the returned job relates to build_harness_submit and build_harness_status.

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?

The tool takes no parameters, so there are none to document and the baseline of 4 applies. The description does enumerate the payload the caller receives, which is helpful framing even though it is not a parameter.

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 action (fetch the one next job in a build) and enumerates the payload it returns: what to do, the only files you may change, the text you need, and how it will be checked. That is far more concrete than the name alone. It does not distinguish itself from the sibling tool 'next', which could plausibly mean the same thing, so it stops short of a 5.

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?

'Do only this job' constrains what to do with the result but says nothing about when to call this tool versus 'next', 'build_harness_status', 'build_harness_submit', or 'readiness'. There is no explicit when/when-not guidance or named alternative.

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

build_harness_statusA
Read-only

Where the current build job stands: steps done, the current step, checkpoints. Call this first in a new chat.

NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the result is a snapshot of job progress (steps done, current step, checkpoints), but says nothing about behavior when no job exists or how the status is refreshed.

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 short sentences, the payload description first and the usage cue second. Every clause earns its place, with no restatement of the name or annotations.

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 no input parameters and no output schema, the description carries the burden of describing the return value, and it does so at a useful level (progress, current step, checkpoints). Minor gap: it does not say how 'no active job' or error states appear in the response.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-related gaps are possible.

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 resource (the current build job's status) and enumerates what it reports: steps done, current step, checkpoints. That differentiates it reasonably from siblings like build_harness_next or readiness, though it never names those alternatives explicitly.

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?

"Call this first in a new chat" gives a clear, actionable trigger condition for invoking the tool. It does not explicitly state when to prefer build_harness_next or readiness instead, so there is no exclusion guidance.

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

build_harness_submitA
Destructive

Say the job is done. The harness checks your change; if it fails, your change is put back and you get the reasons. Never claim it works yourself.

NameRequiredDescriptionDefault
noteNo

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the destructiveHint:true annotation, the description explains the actual mechanism: on failure the change is reverted ('put back') and reasons are returned. That reversion semantics is exactly the kind of context annotations can't express, though success-path behavior and any rate/size limits go unstated.

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?

Three short sentences with zero filler; the primary action is front-loaded and each sentence adds distinct information.

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?

For a low-complexity no-output-schema tool, it covers the failure return ('the reasons') and the reversion behavior well. It leaves the success return and the note param implicit, but the core loop is complete.

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 optional 'note' parameter has 0% schema description coverage and the description never mentions it, so an agent gets no guidance on what the note is for or whether to provide 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?

'Say the job is done' plus 'the harness checks your change' conveys a submit-for-validation action tied to the harness workflow. It's clear but doesn't explicitly differentiate itself from siblings like build_harness_next or run.

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?

'Never claim it works yourself' implies this is the correct way to signal completion instead of self-asserting, and it describes the failure consequence. It stops short of naming alternatives or explicit when-not-to-use conditions.

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

describeA
Read-only

Show a tool's card (use the exact name discover gave): inputs with types, safety, how it is verified. For a recipe: the problem, the steps, the key facts and what happened when it was done.

NameRequiredDescriptionDefault
toolYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so safety needs no restating. The description instead adds value the annotations don't: it discloses the shape of the returned payload, including that recipe entries report 'what happened when it was done' — genuinely useful context beyond the structured fields.

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, no filler, with the core action front-loaded. The recipe clause is telegraphic and slightly compressed, but it carries distinct information rather than padding.

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, and the description correctly takes on the burden by describing what comes back for both tool cards and recipes. For a one-parameter read-only lookup this is nearly sufficient; only error/not-found behavior is left unstated.

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?

With schema coverage at 0%, the description must compensate for the single 'tool' parameter, and it does by specifying the value must be the exact name returned by discover — a real semantic constraint (case/format sensitivity) not present in the schema. It stops short of describing failure behavior for unknown names.

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 ('Show a tool's card') and enumerates the card's contents (inputs with types, safety, verification), so it is clearly distinguishable from discover (which names tools) and run (which executes them). 'Card' is mild jargon but is immediately unpacked by the content list.

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 parenthetical 'use the exact name discover gave' establishes the workflow context: this is the step after discover and before run. It gives clear when-to-use context but states no exclusions (e.g. what happens if the name is wrong, or when describe is unnecessary).

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

discoverA
Read-only

START HERE. Fieldkit has hundreds of tools on this computer that are NOT listed as separate tools: the TV and HDMI, fans and cooling profiles, Word, Excel and PDF files, privacy checks, disk sizes, Wi-Fi and the network, backups, icons, builds and more. Search them here with the person's own words BEFORE you ever say Fieldkit cannot do something. Returns up to 8 tools, most trusted first, with their exact names and inputs (a trailing ? means optional), and RECIPES: how something was done on this computer before, to read with describe and follow, never to run.

NameRequiredDescriptionDefault
goalYes

TDQS

A4.6/5.0
Behavior4/5

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

With readOnlyHint/non-destructive annotations already covering the safety profile, the description adds genuinely new behavior: a cap of 8 results, trust-based ordering, the exact name+input format returned, the '?' optional-suffix convention, and the existence of RECIPES objects. It stops short of saying what happens on a zero-result search or whether repeated searches are cheap, so it is strong but not exhaustive.

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?

The essential instruction and routing rule are front-loaded in the first two sentences, and the return-format details follow. The middle domain list is long but each example widens the agent's sense of scope, so little is truly wasted; the paragraph is dense rather than bloated.

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 single-parameter, non-destructive lookup with no output schema, the description supplies everything an agent needs: when to call it, what the input should look like, how many results come back, their ordering, and how to interpret the returned RECIPES. No structural gaps remain.

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 coverage is 0% for the single `goal` parameter, so the description must carry the meaning — and it does, specifying natural-language input in 'the person's own words' rather than exact tool names or keywords. That is a meaningful semantic constraint beyond the bare `type: string` in 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?

The description opens with an imperative ('START HERE') and states precisely what the tool does: searches a hidden catalogue of hundreds of local tools using the person's own words. It lists concrete example domains (TV/HDMI, fans, Word/Excel/PDF, Wi-Fi, backups) so an agent can immediately tell this apart from siblings like run or describe, which operate on already-discovered tools.

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 an explicit trigger ('BEFORE you ever say Fieldkit cannot do something') and an explicit routing rule for the alternative path: RECIPES are 'to read with describe and follow, never to run.' The when-to-use, when-not-to-use, and which-sibling-next conditions are all present.

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

nextD
Destructive

For a pipeline (e.g. debian-kernel): the one next thing to do.

NameRequiredDescriptionDefault
pipelineYes

TDQS

D1.9/5.0
Behavior1/5

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

Annotations declare readOnlyHint=false and destructiveHint=true, so this is a mutating, potentially destructive operation, yet the description frames it as a benign query about what to do next and says nothing about what state changes or is destroyed. The framing actively works against the annotation signal rather than supplementing it.

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

Conciseness3/5

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

It is a single short sentence with no filler, which is good, but the brevity is under-specification rather than economy; the scoping hint is front-loaded while the actual behavior is absent.

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

Completeness2/5

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

For a destructive, single-parameter tool with no output schema, the description should at minimum state what the tool returns and what side effect it has. Neither is covered, and no annotations detail compensates beyond the raw hints.

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 the single 'pipeline' parameter, so the description carries the burden and only partially does so: the example 'debian-kernel' hints at identifier format, but nothing explains accepted values, naming conventions, or what an invalid pipeline yields.

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

Purpose2/5

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

The phrase 'the one next thing to do' restates the tool name 'next' rather than naming a concrete operation or return type. It mentions a pipeline scope, but an agent cannot tell whether this returns a recommended step, advances state, or both, and it is not distinguished from siblings such as run, readiness, or build_harness_next.

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?

'For a pipeline (e.g. debian-kernel)' only narrows the input domain; there is no statement of when to call this versus run, undo, readiness, or describe. No prerequisites, no ordering guidance, and no exclusions are given.

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

readinessB
Read-only

How many tools are verified / tested / carded / draft.

NameRequiredDescriptionDefault

No parameters

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare this a safe, closed-world read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds only the four stage labels being tallied and says nothing about the shape of the result, aggregation window, or freshness of the data.

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

Conciseness3/5

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

It is a single short fragment with no waste, but it is under-specified rather than concise — the key verb and result shape are simply absent rather than compressed.

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 output schema, the description must explain return values, and it only implies 'counts per stage' without stating it. For a trivial zero-parameter read tool this is close to adequate, but the ambiguity about what the response actually contains is a real gap.

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?

The tool takes zero parameters, so there is nothing for the description to compensate for; baseline 4 applies.

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

Purpose3/5

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

The description names the resource (tool counts by readiness stage) and lists the stages, but it is a sentence fragment with no verb — it never says whether it returns counts, lists, or a readiness ratio. An agent can guess it is a status-aggregate tool, but it is not clearly differentiated from siblings like build_harness_status.

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 indication of when to call this versus build_harness_status or build_harness_next, both of which also sound like status tools. The agent is left to infer the trigger condition entirely.

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

runA
Destructive

Run a tool found with discover, by its exact name, with named inputs. Tools that change things: use mode=preview first (nothing changes), then mode=apply. Irreversible tools need the owner. Tools that go online need network=true.

NameRequiredDescriptionDefault
modeNo
toolYes
inputsNo
networkNo

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the description's job is to add context – and it does: preview changes nothing, irreversible operations require the owner, and online operations need network=true. This is meaningful workflow and safety context beyond the annotations, though it doesn't state what happens if preview is skipped on an irreversible tool.

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?

Three short sentences, each earning its place, with the core dispatch action front-loaded and workflow/safety rules following. No redundancy.

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 meta-tool that dispatches arbitrary tools with nested inputs, no output schema, and 0% param coverage, the description is adequate on workflow and safety but silent on what comes back from the dispatched call and how `inputs` must be shaped. An agent could still invoke it, but with uncertainty.

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 0%, so the description must carry the load. It touches all four parameters (tool name, named inputs, mode workflow, network) but leaves the nested `inputs` object vague – no hint that it is an arbitrary key-value map conforming to the discovered tool's schema. Partial compensation for the coverage 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 and resource ('run a tool found with discover, by its exact name') and ties itself to the discover sibling as the prerequisite. It's clear what it does, though it doesn't differentiate itself from siblings like describe or undo beyond the discover reference.

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 explicit conditional guidance: use mode=preview first for mutating tools, then mode=apply; irreversible tools need the owner; online tools need network=true. That's clear when-to-use context, but it never says when NOT to use this tool or when describe/undo would be the better choice.

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

undoA
Destructive

Put back the files a previous run changed (by run_id).

NameRequiredDescriptionDefault
run_idYes

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false; the description is consistent, describing a restoration write. It adds the key behavioral fact that the reversal is keyed to a run_id, but omits whether current file contents are overwritten, whether the operation is itself reversible, and 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?

A single front-loaded sentence with the verb, object, and scoping parameter — zero waste.

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 destructive restore with one undocumented parameter and no output schema, the description covers the core mechanics but leaves gaps: interaction with files created after the run, overwrite behavior, and confirmation/authorization expectations.

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?

With schema coverage at 0%, the description is the only source of meaning for run_id, and it does clarify that run_id identifies the previous run whose changes are being reverted. It does not describe format, whether it must match a successful run, or error behavior for unknown ids.

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 ('Put back') and resource ('the files a previous run changed') scoped by run_id, which is clear enough to distinguish from siblings like run/next/readiness. No explicit naming of a sibling alternative, but the operation is unambiguous.

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 the use case (revert changes from a prior run) and a precondition (a run must have changed files), but gives no explicit when-not guidance or alternatives for partial/selective reverts.

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. 1 tool updatev0.3.0
    • Changedrun1 field changed
      • addedInput schema / properties / network
        Added value: +{
+  "type": "boolean"
+}
  2. 10 tool updatesv0.1.0
    • First observedbuild_harness_briefs
    • First observedbuild_harness_next
    • First observedbuild_harness_status
    • First observedbuild_harness_submit
    • First observeddescribe
    • First observeddiscover
    • First observednext
    • First observedreadiness
    • First observedrun
    • First observedundo
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

B3.2/5.0

Scored across 10 tools

Disambiguation3/5

The core loop (discover → describe → run → undo) is clearly distinct, but two pairs of tools blur together: `next` (next pipeline step) vs `build_harness_next` (next build job), and `readiness` (tool catalog stats) vs `build_harness_status` (build job stats). Entry-point guidance also conflicts, with `discover` saying 'START HERE' and `build_harness_status` saying 'Call this first in a new chat', forcing the agent to guess which applies.

Naming Consistency3/5

Two different conventions coexist: bare single words (discover, describe, run, undo, next, readiness) and a consistent `build_harness_*` prefix family. Each cluster is internally readable, but there is no single predictable pattern, and the bare verbs mix actions with a noun (readiness) and a temporal word (next).

Tool Count5/5

Ten tools is well-scoped for a meta-server that fronts hundreds of underlying capabilities rather than exposing them individually. Every tool earns its place: a discovery/execution loop, reversibility, catalog health, and a build workflow.

Completeness4/5

The invocation lifecycle is fully covered (find, inspect, execute with preview/apply, undo), and the build harness covers status/next/submit/briefs. Minor gaps remain: the agent explicitly cannot record an answer to a brief, and there is no way to enumerate or browse the catalog outside a search query, which is a dead end when a user's wording does not match.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • a0

    Joe-Simo
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to open, edit, check, run, emit, and save source programs through structured, revision-checked tools over stdio, confining paths to the launch root and returning diagnostics with fixes for rejected edits.
    4 npm
    1
    Apache 2.0

  • Strata Coder

    huyinghuan
    A
    license
    Not graded
    quality
    F
    maintenance
    Enables a primary coding agent to delegate bounded implementation and repair tasks to a local OpenAI-compatible model that edits a copy of the project, runs configured checks, and returns artifacts for review. Exposes stdio tools for capability discovery, task submission, progress polling, artifact reading, and cancellation.
    MIT

  • collab-charter

    LucasDevKid9
    A
    license
    Not graded
    quality
    A
    maintenance
    Exposes 14 tools that let an agent query charter clauses, route and execute an 8-stage collaboration pipeline, arbitrate conflicts with cited clause IDs, enforce safety gates, run receipt self-checks, deposit and recall memory, solve symbolic anchoring constraints, and mine a 330-entry knowledge base plus semantic-field analysis. It also diagnoses image-generation prompts against a formal feature-cluster grammar, all over a zero-dependency stdio JSON-RPC interface.
    1
    MIT