nightward
OfficialServer 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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| nightward_runA | Run the tests, capture behaviors, and return the boundary signal. |
| nightward_statusA | Read the boundary signal of the LAST nightward_run, without running tests. |
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 2 tools
nightward_run executes pytest and produces a fresh verdict, while nightward_status only reads the last persisted report; the two are mutually exclusive in intent. Both descriptions explicitly warn against the classic confusion (status does not see newer code edits), which removes any residual ambiguity.
Both tools share the same `nightward_` prefix with snake_case suffixes, so the set reads as one family. The only minor wrinkle is that `run` is a verb while `status` is a noun, so the pattern is prefix+action rather than a strict verb_noun scheme.
Two tools is genuinely thin, even for a narrow boundary-gating server; the surface could plausibly expose behavior listing or store inspection. It is defensible because the toolset is deliberate and minimal, and approval is intentionally delegated to a human using the CLI.
The core loop (run, then re-read the last verdict) is covered end to end, including rich diagnostics about unapproved and unchecked behaviors. However, there is no way to enumerate stored behaviors, inspect a single behavior, initialize or refresh a baseline, and no approval path at all — the agent must fall back to asking a human for any state-changing operation.