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 | Find tools for a goal, in plain words. Returns up to 5 tools, most trusted first, with their inputs (a trailing ? means optional). |
| describeB | Show a tool's card: inputs with types, safety, how it is verified. |
| 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. |
| undoB | 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. |
| readinessC | How many tools are verified / tested / carded / draft. |
| build_harness_statusA | Where the current build job stands: steps done, the current step, checkpoints. Call this first in a new chat. |
| 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. |
| 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. |
| 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
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 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.
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.
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.