Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
nightward_runA

Run the tests, capture behaviors, and return the boundary signal.

Call this after every code edit: nightward_status only reports the last run.
path: what pytest runs (relative to the server's working directory); omit it to
run the project's capture suite ([tool.nightward] path, else ".");
dir: omit it - the server gates the store a human started it with
(`nightward mcp --dir`), and any other store is refused; timeout: seconds
before pytest is stopped (the store is then left untouched and the last
report invalidated).
Returns {boundary, unapproved, changes: [{name, kind, group, judged,
judge_model, judge_reason, judge_replayed, rejected, rejected_by, depth,
ask_human}], judged_same,
not_run (approved behaviors whose test was deselected: not checked), narrowed,
stale, incomplete, generated_at, judge, scrub_rules (custom scrub rules of the run
and what they replaced), env_mismatch (changed behaviors approved on another OS or
Python than this run, or null: tell the human - it never makes a breach
acceptable), store (absolute path of the gated
store), path (what pytest ran), warnings: {skipped, failed, errors, deselected,
xfailed, scrubbed,
scrub_unmatched (custom scrub rules that matched nothing), scrub_rules (per custom
rule: values and behaviors it replaced, and whether that changed since the last run),
judge_added (judge ruling files this run added to the store's judge/ dir - a human
commits them with the baseline), pytest_returncode, pytest_output_tail}}.
boundary is one of:
  "intact"     done: no unapproved change;
  "breached"   unapproved changes: fix the code, or ask a human to approve;
  "partial"    nothing unapproved among what ran, but approved behaviors were
               not checked (their test was deselected, see not_run): not done -
               run them (remove the -k/-m selection); you can't waive this;
  "incomplete" nothing unapproved, but capture tests failed or errored
               (see incomplete and pytest_output_tail): fix the tests;
  "stale"      the baseline, capture or rejections moved since the report: run again;
  "unknown"    no report yet: run.
Done means boundary == "intact" and stale is false. Behaviors approved with
semantic=True are judged by the judge the humans committed
([tool.nightward] judge in pyproject.toml, or `nightward mcp --judge`);
"judge" says which, and why it was unavailable if it was. This tool cannot
approve changes: a human does that with the nightward CLI.
nightward_statusA

Read the boundary signal of the LAST nightward_run, without running tests.

It does not see code edits made since that run: after changing code, call
nightward_run for a fresh verdict. Same shape as nightward_run, without
warnings. boundary is "intact" (done), "breached" (unapproved changes),
"partial" (approved behaviors not checked: their test was deselected),
"incomplete" (capture tests failed or errored; see incomplete), "stale"
(the baseline, capture or rejections moved since that run, so its verdict can't be
trusted: run again) or "unknown" (no report yet). generated_at says when
the run happened; store names the store read (dir: omit it, as for
nightward_run).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness3/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues