Skip to main content
Glama
AndersonVitaease

MemoryOS VPS Guardian

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": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.5/5.0

Scored across 10 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues