Which integrations are available for this server?

Provides pipelines and triage for Debian kernel and packaging failures, enabling staged, resumable builds and diagnosis of build issues. Provides a pipeline for the Firefox Windows build harness and triage for Firefox on Windows build failures. Allows gathering tools from GitHub repositories into a local toolbox, recording commit and file hashes, and optionally running their tests.

How do I use Fieldkit?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Fieldkit is this Word file safe to send?" 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.

Fieldkit

by gorillanobakaa-dot

Overview Schema Source Related Servers Discussions Admin

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.

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.
Your AI helper uses it for you, through the "agent door" described in part 1. You stay in charge: anything risky waits for you.

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.

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.
Every tool has a card: what it needs, what it changes, and how risky it is: read-only, reversible or irreversible.
A tool nobody has reviewed is refused, with the reason.
What the AI asks for is checked against the card before anything runs.
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.
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

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

Fieldkit fetches the untouched source of the latest stable Firefox from Mozilla's own release tag and keeps a read-only copy (the vault).
It makes a working copy and applies every Gorilla change that still fits, with no guessing.
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.
Only the leftovers go to the small local model. The model answers in text; Fieldkit makes the edit and checks the file.
Anything that needs human judgement is parked for the maintainer with a written explanation.
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:

Every changed JavaScript file must parse.
Every name a file imports must still exist in the file it comes from.
No build list may be left empty.
Every change must be explained by the previous release or by a recorded step (truthbound).
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

Backup. The installed browser and your profiles are zipped into Documents\Gorilla.Firefox.Backups, with a fingerprint list.
Install from the fingerprinted zip, not the installer: the installer once reported success after installing nothing.
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.
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.
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.
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: machine-mcp

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.

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:

Read-only tools run straight away.
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.
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. 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.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it declares 'Read-only' up front and states the critical constraint that the agent cannot record an answer — only the person can, at a terminal. It does not describe return volume or pagination, but the safety and permission profile is clearly disclosed.

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 'Read-only.' lead is front-loaded, and the remaining sentences each add distinct information (brief contents, id behavior, the answering constraint). Dense but every clause earns its place; the parenthetical listing of brief contents is slightly long but useful.

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 read-only tool with one optional parameter, no output schema, and no annotations, the description covers what is returned, how the id parameter changes behavior, and the key constraint on recording answers. Nothing essential for correct invocation is missing, though the relationship to sibling harness tools is left implicit.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it does: 'Optional id: one brief in full' explains both the optionality and the behavioral difference between passing an id (one brief) versus omitting it (all briefs). This is meaningful semantics beyond the bare string type in 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?

The description states a clear resource: 'the decisions waiting for the person, each as a full brief,' and enumerates the brief's contents (what is affected, options and costs, recommendation). It does not explicitly differentiate from siblings like build_harness_next or build_harness_status, but the resource returned is specific enough to identify the tool.

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?

'Show the brief instead of asking a question' gives a clear directive for when to invoke it, and 'You cannot record an answer: only the person can, at a terminal' establishes the boundary of use. It stops short of naming an alternative tool for the answering path, so it is context rather than explicit routing.

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

build_harness_nextA

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the payload shape and a scoping constraint ('the only files you may change'), but never says whether calling it advances harness state, whether it is idempotent, or how it behaves when the build is complete.

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

Conciseness5/5

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

A single front-loaded sentence that enumerates the returned payload and closes with the key constraint. No filler, no restatement of the name.

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, no annotations, and no parameters, so the description is the sole source of truth. It covers what comes back but omits stateful workflow behavior (advancing, completion, re-invocation), leaving a real gap for a multi-step harness 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4.

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 resource and payload: the next job in a build, including the task, the only editable files, the text needed, and the check. This tells an agent what it gets, but it never explicitly distinguishes itself from near-name siblings like 'next' or '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 Guidelines3/5

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

'Do only this job' implies this is the tool to call to obtain the next unit of work, but it names no alternatives and gives no condition for choosing it over 'build_harness_status' or 'build_harness_briefs'. Usage is implied rather than stated.

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

build_harness_statusA

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

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations and no output schema, the description carries the full burden, and it does disclose the return content (steps done, current step, checkpoints). However, it never states that this is a read-only, side-effect-free operation, nor any auth or rate-limit considerations, so the behavioral profile is only partially covered.

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 with no filler; the returned-content summary is front-loaded ahead of the usage cue. Every phrase earns its place.

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 zero-parameter status tool with no output schema, the description supplies both the expected return shape and the trigger condition, which is enough for an agent to call it correctly. It could be stronger by confirming the read-only nature and whether a build job must already exist.

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 and the baseline of 4 applies. No parameter-related gaps exist.

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 names a specific resource (the current build job) and enumerates the returned content (steps done, current step, checkpoints), which separates it from siblings like build_harness_next or build_harness_submit. It is a clear status read rather than a tautology of the name, though the phrasing 'where the current build job stands' is slightly indirect.

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?

It gives explicit invocation guidance: 'Call this first in a new chat.' That is a concrete when-to-use condition. It stops short of naming alternatives (e.g., discover or readiness) or stating when not to call it, so it lands below the top band.

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

build_harness_submitB

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.

ParametersJSON Schema

Name	Required	Description	Default
`note`	No

TDQS

B3.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the harness verifies the change, reverts it on failure, and returns the reasons. It stops short of covering permissions, what exactly 'put back' restores, or whether submission is final.

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?

Three short sentences, front-loaded with the core action and followed by the consequence and the constraint. No filler, though the informal 'Say the job is done' phrasing is slightly looser than a precise imperative.

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 one-parameter submit tool with no annotations or output schema, the description covers the essential behavior and failure semantics, but leaves the only parameter entirely unexplained and omits any prerequisite or auth context.

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 'note' parameter has 0% schema description coverage and is never mentioned in the description, so an agent gets no guidance on its purpose, format, or whether it is required. The description does not compensate for the 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?

The description conveys a specific action — submitting a completed change to the harness for verification — and clarifies the consequence (harness checks it, rolls back on failure). It is understandable without opening the schema, though it never names or distinguishes itself from siblings like build_harness_status 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 Guidelines3/5

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

Timing is implied ('Say the job is done') and the closing line 'Never claim it works yourself' hints that this tool replaces self-asserted success, but no explicit alternatives or when-not conditions are given. Usage context is inferable rather than stated.

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

describeB

Show a tool's card: inputs with types, safety, how it is verified.

ParametersJSON Schema

Name	Required	Description	Default
`tool`	Yes

TDQS

B3/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden, and it does add real value by naming what the response contains (input types, safety, verification). It still omits whether the call is side-effect free, what happens for an unknown tool name, and any auth/permission requirement — gaps that matter when nothing else documents behavior.

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

Conciseness4/5

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

A single tight sentence, front-loaded with the verb and followed by the most useful detail. No filler or repetition. The only minor cost is the undefined jargon term 'card', which the colon list partly repairs.

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?

The tool is low-complexity (one lookup) but has no output schema and no annotations, so the description is the only source for return shape and behavior. It sketches the return contents, which is the minimum needed, yet leaves the input format and error behavior unspecified.

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% and the single required parameter 'tool' is undocumented in both schema and description. 'A tool's card' weakly implies the argument is a tool identifier, but the accepted form (name, id, slug) is never stated, so the description does not compensate 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 ('Show') and resource (a tool's card), then enumerates the card's contents (inputs with types, safety, verification), which makes the artifact concrete rather than tautological. It does not distinguish itself from the sibling 'discover', which likely also surfaces tool information, 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?

There is no when-to-use, when-not-to-use, or alternative routing. With siblings like 'discover' and 'readiness' in the same namespace, an agent gets no cue about which lookup to pick. Usage must be entirely inferred from the tool name.

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

discoverA

Find tools for a goal, in plain words. Returns up to 5 tools, most trusted first, with their inputs (a trailing ? means optional).

ParametersJSON Schema

Name	Required	Description	Default
`goal`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full load, and it does disclose real behavioral detail: a cap of 5 results, trust-based ordering, and input notation (trailing ? = optional). It omits other useful traits — whether the match is semantic or keyword-based, behavior on zero results, and any freshness/side-effect notes — so it is informative but incomplete.

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

Conciseness5/5

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

Two sentences, no waste, with the core purpose front-loaded and the return-format detail following. Every clause adds information the schema does not carry.

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

Completeness4/5

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

There is no output schema, so the description correctly steps in to explain the return shape (up to 5 tools, trust-ordered, with inputs). For a single-parameter discovery tool this is nearly sufficient; only edge cases like no matches or how to request more results are unaddressed.

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?

One parameter with 0% schema coverage, so the description must compensate, and it does: the goal is described as free-form "plain words", clarifying the expected input style beyond the bare `string` type. It does not give length limits or example queries, so it stops short of full coverage.

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 ("Find tools") plus the input modality (a goal in plain words), so an agent immediately knows this is a discovery/search tool. It is not explicitly contrasted with siblings like describe or run, but the purpose is unambiguous against the rest of the list.

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?

Implied usage is clear — call this when you have a goal and need to locate a tool — and "in plain words" hints at how to phrase the request. However there is no explicit when-not guidance, no mention of how this relates to describe/run, and no note on what to do when no tool matches.

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

nextD

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

ParametersJSON Schema

Name	Required	Description	Default
`pipeline`	Yes

TDQS

D1.5/5.0

Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says nothing about whether the operation is read-only, what side effects it might have, what the returned 'thing' is, or any auth/permission requirements. The agent is left entirely blind to the tool's behavior.

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

Conciseness2/5

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

The description is a single short clause, but it is under-specified rather than optimally concise. It fails to front-load any actionable information beyond a vague statement and one example. The brevity does not earn its place because essential details are missing.

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

Completeness1/5

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

With no annotations, no output schema, no sibling differentiation, and only one parameter with 0% schema coverage, the description is far from complete. An agent would have to guess the return format, side effects, and when to choose this tool over siblings like build_harness_next. It is inadequate for even a simple query tool.

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% and the single parameter 'pipeline' has no schema-level description. The description gives one example value ('debian-kernel'), which offers minimal semantic help but does not explain format, constraints, or what constitutes a valid pipeline identifier.

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 description 'the one next thing to do' largely restates the tool name 'next' and adds only a pipeline scope. It lacks a clear verb (e.g., return, recommend, fetch) and does not differentiate itself from the sibling build_harness_next. The agent cannot confidently tell what the tool actually returns or how it differs from similar tools.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus alternatives such as build_harness_next or readiness. The single example '(e.g. debian-kernel)' is context for the parameter, not usage guidance. No prerequisites, exclusions, or alternative routing are provided.

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

readinessC

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

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden, yet it only names output categories. It does not state that this is a read-only counting operation, whether it requires any auth, or how results are grouped. The listed categories (verified/tested/carded/draft) are modestly useful context but far from complete.

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

Conciseness4/5

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

A single short sentence with the core information front-loaded and no filler. It is efficient, though the fragment structure and slash-separated list are slightly informal.

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 zero-parameter, no-output-schema reporting tool, the description roughly tells the agent what it returns. But it never defines what the readiness categories mean or what form the counts take, leaving a small but real gap for an agent deciding whether this answers its question.

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 no parameter semantics to document. Per the baseline for a parameterless tool, a 4 is appropriate since the schema is empty and needs no elaboration.

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 conveys that this reports counts of tools grouped by readiness state (verified/tested/carded/draft), which is a specific resource. However the verb is only implied by 'How many', and nothing distinguishes it from siblings like build_harness_status or describe. A reader can guess the purpose but not confidently tell it apart from related status tools.

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 alternatives such as build_harness_status or discover. No context, prerequisites, or exclusions are given. The agent must infer usage entirely.

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

runB

Run a tool 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.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No
`tool`	Yes
`inputs`	No
`network`	No

TDQS

B3/5.0

Behavior3/5

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

With no annotations, the description carries the burden and does disclose real behavior: preview performs no changes, apply mutates, irreversible operations require the owner, and online access needs network=true. However, it says nothing about permissions/authorization model, error or partial-failure behavior, or what the call returns, leaving meaningful gaps for a mutation-capable dispatcher.

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?

Three short sentences, the purpose statement is front-loaded and the operational rules follow in priority order. No filler, though the fragment style compresses detail away rather than genuinely economizing.

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 complex meta-dispatch tool with a nested `inputs` object, no output schema, and zero schema documentation, the description is not sufficient: it omits how tool names are discovered/validated, the expected shape of `inputs`, and return behavior. An agent could not reliably invoke this for an arbitrary tool from this text alone.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate. It explains `mode` semantics (preview changes nothing, apply does), clarifies `network=true`, and implies `tool` is the target name, but `inputs` (a nested object) is completely undescribed and the "owner" concept referenced in the text has no corresponding parameter, which is confusing.

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?

"Run a tool with named inputs" essentially restates the name "run" and adds no specificity: it never says which tools can be run, how the `tool` string is resolved, or how this differs from siblings like `describe`, `discover`, or `undo`. A reader cannot tell from the description whether this is a generic dispatcher, a scheduler, or something else.

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?

It gives clear conditional workflow guidance: preview first for mutating tools, apply afterward, owner required for irreversible tools, network=true for online tools. This is actionable when-to-use advice, though it never names an alternative sibling or an explicit when-not-to-use condition, which keeps it below a 5.

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

undoB

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

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: it does not state whether the undo is destructive, whether it overwrites newer changes, what happens with an invalid or already-undone run_id, or whether it requires confirmation/permissions. Only the basic revert semantics are conveyed.

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

Conciseness4/5

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

A single tight sentence with the action front-loaded and the parameter scoping parenthetical at the end; nothing is wasted. It is arguably too terse for a mutation tool, but structurally it earns its place.

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 state-mutating tool with no annotations and no output schema, the description is incomplete: it says nothing about safety, reversibility, error behavior, or what a successful undo returns. Given the complexity of undoing a run, an agent lacks the context needed to call it confidently.

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% for the single required param, so the schema alone is thin. The description adds that run_id identifies 'a previous run' whose changes are targeted, which gives real meaning, but it omits any format, source, or how to obtain a valid run_id.

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 pairs a specific verb ('Put back') with a specific resource ('the files a previous run changed'), making the operation unambiguous. It does not explicitly contrast itself with siblings like 'run' or 'next', but the wording clearly ties it to reverting a prior run's effects.

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?

Usage is implied rather than stated: it is for reversing changes from a previous run. There is no explicit when-to-use condition, no mention of when not to use it versus alternatives like re-running, and no prerequisites or ordering guidance.

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 tool updatev0.3.0Oct 15, 2026
- Changedrun1 field changed
  - addedInput schema / properties / network
```
Added value: +{
+  "type": "boolean"
+}
```
10 tool updatesv0.1.0Oct 5, 2026
- 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/5.0

Scored 2026-10-15 14:25 across 10 tools

Disambiguation4/5

Most tools have clearly distinct purposes: run/discover/describe/undo handle tool execution and inspection, while build_harness_* tools cover the build workflow. The main overlap is between 'next' for pipelines and 'build_harness_next' for the build harness, but the descriptions make their scopes separable.

Naming Consistency3/5

Naming is mixed: four tools share a clear 'build_harness_' prefix, but the rest are bare verbs or nouns ('run', 'discover', 'describe', 'undo', 'next', 'readiness'). There is no single verb_noun convention across the set, though the names remain readable.

Tool Count5/5

Ten tools is well-scoped for a build-harness and tool-running server. Each tool covers a distinct area of the workflow, with no obvious redundancy or thin surface.

Completeness4/5

The surface covers core lifecycle actions: inspecting tool readiness, discovering/describing/running tools, undoing changes, and managing build harness status, next steps, submissions, and briefs. A minor gap is that the agent cannot record brief answers by design, leaving that action to a human terminal.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Proofable MCP B
io.github.proofable
Context and control for any AI. Agent identity, scoped access, and proof across tools.
Security Agent Orchestration Autonomous Agents
361
contextq-mcpOAuth
io.github.contextq
Persistent memory, hybrid search and a goal graph for AI agents, over stdio or remote HTTP.
Knowledge & Memory Search RAG Systems
1
FlowraOAuth
io.github.flowradev
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Agent Orchestration Autonomous Agents
11
Oakallow AOAuth
io.github.oakallow
Runtime permission, approval, and audit layer for AI agent tool execution.
Autonomous Agents Security
531

Related MCP Servers

MIDAS
Autonomous Agents Command Line
omarkhandji-commits
A
license
Not graded
quality
C
maintenance
Local-first AI agent for approval-gated automation and verifiable LLM workflows.
Updated 3 months ago (2026-07-31 18:35 UTC)
1
MIT
machine-mcp
Command Line File Systems OS Automation
AndreaGriffiths11
A
license
A
quality
B
maintenance
Enables an AI agent to run local tools on the user's own machine via stdio, including command execution, workspace file read/write, and system status checks.
Updated 2 months ago (2026-08-29 15:18 UTC)
5
2
MIT
a0
Developer Tools File Systems Code Analysis
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.
Updated 4 days ago (2026-10-18 18:53 UTC)
4 npm
1
Apache 2.0
Strata Coder
AI & Machine Learning Developer Tools Agent Orchestration
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.
Updated 18 days ago (2026-10-04 16:57 UTC)
MIT

Fieldkit

What it does (Layman Track)

The idea in one paragraph

How you use it

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

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

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

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

5. Builds, releases and the laptop's temperature

6. The exam: measure your own model

7 to 10. The Gorilla Firefox build harness

7. Porting a new Firefox release

8. Checking the source and building it

9. Installing the browser and proving it works

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

What Fieldkit will never do

Technical Definition (Developer Track)

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

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers