MemoryOS VPS Guardian
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| engineering.vps.healthA | Is my VPS healthy? Returns a deterministic read-only verdict (HEALTHY | DEGRADED | UNKNOWN) built from local OS evidence only (uptime, CPUs, load average, memory). Input must be exactly {}. No mutation, no shell, no SSH, no network, no secrets. |
| engineering.vps.capacityA | Is my VPS close to its capacity limits? Returns a deterministic read-only pressure assessment (OK | PRESSURED | UNKNOWN) for CPU load and memory, built from local OS evidence only. Current state only — no capacity prediction and no upgrade advice. Input must be exactly {}. No mutation, no shell, no SSH, no network, no secrets. |
| engineering.vps.what_changedA | What changed since the previous observation made by this MCP process? Session/process scoped: the first call creates the baseline (BASELINE_CREATED) and later calls compare the current OS evidence (uptime, CPU count, load, memory) against the previous observation of THIS process. Restarting the server resets all history. It does NOT provide deployment, file, service or container history and knows nothing before its baseline. Input must be exactly {}. No mutation, no shell, no SSH, no network, no secrets. |
| engineering.vps.incident.summaryA | Deterministic composition summary: what is happening on this VPS right now according to the local evidence observed by this MCP process? Combines the current health, capacity and change observations. It shares the session history of engineering.vps.what_changed: calling this tool counts as one observation. Returns NORMAL, ATTENTION or UNKNOWN with compact factual notes and fixed limitations. It never claims a root cause and does NOT observe applications, services, containers, deployments or logs. Input must be exactly {}. No mutation, no shell, no SSH, no network, no secrets. |
| engineering.deploy.statusA | What deployment state is reported by the configured application/deployment evidence source? Deterministic read-only verdict (OK | IN_FLIGHT | PENDING | FAILED | UNKNOWN | UNAVAILABLE) built ONLY from the operator-configured release-state evidence source (MEMORYOS_VPS_GUARDIAN_RELEASE_STATE_FILE, read-only JSON file). UNAVAILABLE means no source is configured or it returned no valid evidence; UNKNOWN means a valid source explicitly reported no deployment status. evidenceAgeSeconds is factual evidence age and never changes the verdict. It does not assess application health, VPS health, readiness to deploy or failure causes. Input must be exactly {}. No mutation, no shell, no SSH, no network, no secrets. |
| engineering.app.healthA | What application health state is reported by the configured validated application/deployment evidence source? Deterministic read-only verdict (HEALTHY | DEGRADED | UNKNOWN | UNAVAILABLE) built ONLY from the operator-configured release-state evidence source (MEMORYOS_VPS_GUARDIAN_RELEASE_STATE_FILE, read-only JSON file) — the same source and configuration as engineering.deploy.status; no new configuration. UNAVAILABLE means no source is configured or it returned no valid evidence; UNKNOWN means a valid source explicitly reported no application health. evidenceAgeSeconds is factual evidence age and never changes the status. It does NOT probe the application, inspect Docker, call HTTP, infer health from deployment status, or diagnose root cause. Input must be exactly {}. No mutation, no shell, no SSH, no network, no secrets. |
| engineering.deploy.readyA | Based on currently configured validated operational evidence, does the application satisfy the minimum deterministic prerequisites for attempting a deployment? Deterministic read-only advisory verdict (READY | NOT_READY | UNKNOWN | UNAVAILABLE) computed ONLY by the certified readiness classifier over the operator-configured release-state evidence source (MEMORYOS_VPS_GUARDIAN_RELEASE_STATE_FILE, the same source as engineering.deploy.status) and existing local VPS health/capacity evidence — no new configuration. UNKNOWN means required valid evidence is incomplete; UNAVAILABLE means a required evidence source is unavailable. evidenceAgeSeconds is factual and never changes the verdict. Advisory only: this tool deploys nothing, approves nothing, grants no deployment or recovery authority, does not predict deployment success and does not inspect code, migrations or release contents. Input must be exactly {}. No mutation, no shell, no SSH, no network, no secrets. |
| engineering.docker.healthA | Is the configured Docker/container workload healthy? Deterministic read-only advisory verdict (HEALTHY | DEGRADED | UNKNOWN | UNAVAILABLE) computed ONLY from the operator-configured docker-health evidence source (MEMORYOS_VPS_GUARDIAN_DOCKER_HEALTH_FILE, one fixed operator-controlled JSON file produced outside this process; aggregated counts only). This tool does NOT access the Docker socket, does NOT run the docker CLI, and does NOT probe containers: no shell, no SSH, no network, no secrets, no LLM, no mutation, no deployment or recovery authority. It never infers root causes; UNKNOWN means the valid evidence is incomplete or inconsistent, UNAVAILABLE means the evidence source is unavailable; absence of evidence is never read as HEALTHY. Input must be exactly {} — the agent can never select a container, host, path or socket. |
| engineering.vps.why_downA | Why does the currently configured VPS/application appear unhealthy? Deterministic read-only diagnostic synthesis of the evidence already available to this server: local VPS health and capacity plus the operator-configured application/deployment and docker-health sources when present. It reports normalized signals (VPS_HEALTH, CAPACITY, APPLICATION_HEALTH, DEPLOYMENT, DOCKER), what is degraded, what is unknown and what is not observable — SIGNALS, not root causes: correlation is never presented as causation and no recovery or deployment authority exists. No shell, no SSH, no network probe, no Docker socket, no logs, no secrets, no LLM, no mutation. Input must be exactly {} — the agent can never select a host, application, container or path. |
| engineering.logs.explainA | What do the currently configured operational log signals mean? Deterministic read-only advisory explanations (EXPLAINED | UNKNOWN | UNAVAILABLE) computed ONLY from the operator-configured log-evidence source (MEMORYOS_VPS_GUARDIAN_LOG_EVIDENCE_FILE, one fixed operator-controlled structured JSON file of already-normalized log signals produced outside this process). NOT a log browser: it never reads raw logs, never tails or watches files, never runs grep, journalctl or docker logs, and never touches the Docker socket. Classification is a small deterministic taxonomy (out-of-memory, connection refused, timeout, port-bind failure, DNS failure, health-check failure, process exit, permission failure) matched from producer-supplied codes first; unclassifiable signals are reported as UNKNOWN and evidence messages are never returned. Explanations are advisory: no shell, no SSH, no child processes, no network, no LLM, no mutation, no recovery authority. Input must be exactly {} — the agent can never select a path, file, container, service, journal, query or time range. |
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
Each tool has a clearly named evidence source or verdict type, and the descriptions are unusually explicit about boundaries. The one real overlap risk is engineering.vps.incident.summary vs engineering.vps.why_down, since both synthesize current VPS/app evidence and an agent might not immediately know which to call.
The engineering.<domain>.<suffix> snake_case prefix is consistent and makes tool navigation predictable. The suffix style is somewhat mixed — noun statuses like health, capacity, status coexist with phrasal forms like what_changed, why_down, and explain — but this is a minor inconsistency rather than a serious problem.
Ten tools is well within the ideal range for a read-only diagnostics/observability server. Each tool covers a distinct evidence area or synthesis role, and none feels redundant or superfluous.
The set covers VPS OS health, capacity, change detection, deployment status, application health, deployment readiness, Docker health, diagnostic synthesis, and log-signal explanation. Minor gaps exist — disk/network capacity and deployment history are absent — but the tools work together to cover the core 'guardian' workflow without dead ends.