Skip to main content
Glama
Sign In
sysknife

sysknife

by lacs-project
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

sysknife_doctor

Pings the daemon and reports its configured brain provider/model, audit database path, and audit-chain status (intact, broken, or unknown) for a read-only health check.

Instructions

Diagnose SysKnife: pings the daemon, reports the configured brain provider/model, the audit DB path, and a quick audit-chain status (intact/broken/unknown). Read-only and safe to call without prior sysknife_plan.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
distroYesDetected Linux distribution, e.g. `"Ubuntu 24.04"` or `"Fedora 41"`. Set to `"unknown"` when neither daemon nor local detection supplies it.
warningsYesNon-fatal warnings collected during the diagnostic run. Anything that could not be checked (state, brain config, audit chain, …) adds one entry here so the operator sees what was skipped and why.
brain_modelYesConfigured brain model identifier.
audit_db_pathYesResolved audit DB path. For Postgres deployments, the literal string `"postgres"` instead of a filesystem path.
daemon_socketYesResolved daemon socket target as a URI, e.g. `"unix:///run/sysknife/daemon.sock"` or `"vsock://3:7777"`. Accepted verbatim by `SYSKNIFE_SOCKET`.
distro_sourceNoWhether the distro came from the daemon or the compatibility fallback.
brain_providerYesConfigured brain provider (`"anthropic"`, `"openai"`, `"ollama"`, …).
daemon_reachableYes`true` iff the daemon answered `query_state` within the socket timeout.
audit_chain_statusYes`"intact"` | `"broken"` | `"unknown"`. `"unknown"` covers all `CannotVerify` cases (missing key file, unreachable DB, etc.).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.27.1
    • changedOutput schema / properties / distro / description
      Previous value: -"Detected Linux distribution, e.g. `\"Ubuntu 24.04\"` or `\"Fedora 41\"`.\nSet to `\"unknown (<reason>)\"` when `/etc/os-release` cannot be read."New value: +"Detected Linux distribution, e.g. `\"Ubuntu 24.04\"` or `\"Fedora 41\"`.\nSet to `\"unknown\"` when neither daemon nor local detection supplies it."
    • addedOutput schema / properties / distro_source
      Added value: +{
+  "default": "",
+  "description": "Whether the distro came from the daemon or the compatibility fallback.",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.1.4
    • changedOutput schema / properties / daemon_socket / description
      Previous value: -"Resolved daemon socket target, e.g. `\"Unix(\\\"/run/sysknife/daemon.sock\\\")\"`."New value: +"Resolved daemon socket target as a URI, e.g. `\"unix:///run/sysknife/daemon.sock\"`\nor `\"vsock://3:7777\"`. Accepted verbatim by `SYSKNIFE_SOCKET`."
  3. Addedv0.1.2

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden and does state the key traits: read-only, safe, and that it contacts the daemon (a nonzero-cost probe). It does not say what happens on an unreachable daemon or whether the call can block, leaving a minor gap for a zero-arg health probe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence that front-loads the verb and enumerates outputs in scan order, then a safety clause. No filler, nothing redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description already names the reported facts (daemon, provider/model, DB path, chain status). For a zero-parameter read-only probe, nothing an agent needs in order to call it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. The description correctly keeps its focus on outputs rather than inventing parameter talk.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (diagnose) and enumerates exactly what the tool inspects: daemon reachability, brain provider/model, audit DB path, and audit-chain status. That enumeration distinguishes it from neighbors like sysknife_audit_verify and sysknife_collect_diagnostics without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Safe to call without prior sysknife_plan" gives a concrete precondition cue tied to the plan/execute workflow, which is the main decision an agent faces. It stops short of explicitly routing away from sysknife_audit_verify or sysknife_collect_diagnostics, so alternatives are only implied by "quick".

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools