protect-context
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PC_USER_DIR | No | Overrides the personal-layer directory (default $XDG_CONFIG_HOME/protect-context or ~/.config/protect-context) | |
| PC_SESSION_ID | No | Names the session used for evidence and loop views, so parallel hosts do not share a view |
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": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| guard_statusB | Dashboard: session, diff delta, loop streaks, evidence count, contract size, last verify. |
| guard_verifyA | Run a command and RECORD the outcome as evidence (id, exit, digest) in
verify_runs.jsonl. shell=True is by design: the command runs verbatim with
the caller's own privileges — this is an evidence ledger, not a sandbox.
Never raises on nonzero exit; failures are recorded and the text says why
and how to re-run. Exit 0 from a pipeline or a failure mask ( |
| guard_evidenceA | Recent verification runs, or one run in full by evidence id. Passing an id returns the complete record (digest tail, why, fix) so a past failure can be read back instead of only counted. |
| guard_contractA | Contract store: action="list" | "add" (with text) | "remove" (with id). Seed constraints (source="seed") cannot be removed by the model — the owner removes them via the CLI or /guard-contract, so a model cannot delete its own injected guardrails (e.g. 02-evidence-before-success). |
| guard_noteA | Journal an agent-authored entry with a durable Tag it |
| guard_journalC | Read recent journal entries, optionally filtered by journal type. limit is clamped to a compact, finite range at the journal boundary. |
| guard_recallA | Search the retained journal and evidence window. No embeddings. Keywords are case-insensitive substrings of text, cmd, and digest; every keyword must match (a keyword that is itself ev-NNNN also matches that evidence id). tags are AND and case-insensitive; evidence rows have no tags, so a tag filter excludes them. type is decision|correction|risk|note |evidence. evidence_id is an exact ev-NNNN id (ev-7 and ev-0007 match). cmd is a fingerprint or substring of a verify run. Hits are ranked by match strength, then recency, and labelled trusted or agent. Read-only: does not create the store. limit is clamped to 0–20 (default 5). |
| guard_loop_checkC | Failing-command streaks for this session + change-strategy advice. |
| guard_diff_auditB | Diff audit vs HEAD (or a baseline ref): numstat stats + verdict vs thresholds. |
| guard_preflightB | Tool presence/versions for configured tools + git-repo check. |
| guard_budgetB | Session tool-output chars, estimated tokens (chars/4), top-5 tools. |
| guard_orientationB | Bounded repository tree, language counts, and conventions files. |
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 12 tools
Most tools have clear distinct roles (verify vs. note vs. contract mutate different stores), and descriptions carefully delineate read/write boundaries such as guard_evidence vs. guard_recall vs. guard_journal. The main soft overlap is the aggregate view tools — guard_status, guard_budget, guard_loop_check, and guard_diff_audit all surface session/diff telemetry, so an agent may hesitate over which one answers a given question.
Every tool uses the same guard_ prefix with lowercase snake_case and a compact noun/noun-phrase form (guard_diff_audit, guard_loop_check, guard_orientation). No camelCase, no stray prefixes, and the pattern is entirely predictable.
Twelve tools sits comfortably in the well-scoped range for a session-guardian server. Each tool maps to a distinct store or check (contract, journal, evidence, budget, diff, preflight), so none feel padded.
Lifecycle coverage is strong: contract is list/add/remove, journal is write/read/search, evidence is record/list/inspect, plus status, budget, diff, loop, and orientation checks. Minor gaps remain — no way to remove or prune recorded evidence, and no explicit session reset/clear operation — but agents can work around these.