context-harness
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAI_API_KEY | No | OpenAI API key used only when explicitly enabling the decisions or responses search backend. | |
| CONTEXT_HARNESS_HOME | No | Changes the root directory where context-harness state is stored. | |
| CONTEXT_HARNESS_HOOKS | No | Set to off to disable the context-harness hooks. | |
| CONTEXT_HARNESS_STATE | No | Overrides the state location used by the CLI, MCP server and hooks. | |
| CONTEXT_HARNESS_HOOK_TTL_HOURS | No | How long hook-related task state remains active, in hours. | 12 |
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 | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| startB | Start a coding task: snapshot pre-existing tests, return memory pointers/lessons and a run budget. Call once per task. |
| runA | Run a test/check command in the project under the task budget. Returns exit code, failing tests, first failure and the log path (full log stays on disk). full=true for the complete check. Wait for the result; a refusal means: stop and report. |
| guardC | List pre-existing tests whose lines were rewritten or deleted. With run_template (containing {files}) run the original tests against the current code. |
| reportB | Finish the task: status, summary, changed files and evidence. Rewritten pre-existing tests need test_changes entries 'PATH: why'. |
| searchC | Search project memory: verified lessons/facts in full, code as file pointers. |
| rememberB | Propose a project lesson that is not visible in the code (stored unverified). |
| checkpointC | Current task state for resuming: criteria, latest reports, budget. |
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 7 tools
Each tool targets a distinct phase of the task lifecycle: start (begin), run (execute tests), report (finish), checkpoint (resume state), search/remember (read/write memory), guard (test-integrity check). The only mild overlap is start vs checkpoint, since both surface task/budget state, but their descriptions differentiate begin-task from resume-task.
All names are single lowercase words with a consistent terse style (start, run, report, search, remember, guard). The one deviation is checkpoint, a noun rather than a verb, but it still fits the minimal naming convention.
Seven tools is well-scoped for a coding-task harness: three cover the task flow (start/run/report), two cover memory, and two cover resumption and test integrity. Each tool earns its place with no redundancy.
The surface covers the full task lifecycle plus memory and integrity checks, which is strong. Minor gaps exist around memory management (no listing/deleting or verifying lessons) and checkpoint has no explicit restore counterpart, but agents can work around these.