Fieldkit
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| discoverA | START HERE. Fieldkit has many tools on this computer that are NOT listed as separate tools (to COUNT them, call readiness): 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. |
| describeA | 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. |
| runA | 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. |
| undoA | Put back the files a previous run changed (by run_id). |
| nextD | For a pipeline (e.g. debian-kernel): the one next thing to do. |
| readinessA | COUNTS Fieldkit's tools, measured now: the total on this computer and how many are verified / tested / carded / only gathered. Use it to answer 'how many tools do I have'. |
| build_harness_statusA | Where the current build job stands: steps done, the current step, checkpoints. Call this first in a new chat. |
| build_harness_nextB | 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. |
| build_harness_submitA | 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. |
| 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
build_harness_next and next both promise 'the one next thing to do' with nearly identical phrasing, so an agent can easily pick the wrong one. discover vs readiness also partially overlap (both inventory tools), though their descriptions differentiate counting from searching. The discover/describe/run triad and undo are clearly distinct.
The build_harness_* family is internally consistent and namespaced, but the rest are bare single words—verbs (discover, describe, run, undo) mixed with nouns (readiness, next). No unified convention spans the set, though each name is still readable and inferable.
Ten tools is well within the ideal range and each maps to a distinct role: discovery, inspection, execution, revert, inventory counting, and a four-step build-harness loop. Nothing feels padded or missing at the count level.
The discovery lifecycle (discover → describe → run with preview/apply → undo) and the build loop (status → next → submit, plus briefs) are well covered. Minor gaps: no explicit way to list prior run_ids or browse run history for undo, and answer-recording is delegated to the human by design—understandable but a dead end for the agent.