Skip to main content
Glama
Sign In
zb-ss

Servonaut

by zb-ss
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

build_server_memory

Probe enabled server modules over SSH and cache the results to create a fresh memory snapshot for a managed instance. Use when memory is missing or a full rescan is needed.

Instructions

Build memory from scratch for a managed instance — probes all enabled modules (OS, runtimes, services, web stack, logs, etc.) over SSH and writes the results to the local cache. Call this when get_server_memory returns code='missing', or when you want a fresh full scan. Returns JSON with: instance_id, count (successful modules), successes (list of module names), failures (list of {module, reason, message}), and — when count=0 — an overall 'reason' code (opt_out | disabled | no_modules_matched | all_probers_failed | host_key_verification_failed | ssh_connection_failed). If reason='all_probers_failed' the failures list explains per-module (usually an SSH reachability / auth problem — fix that before retrying). host_key_verification_failed and ssh_connection_failed mean nothing reached the server and the stored memory was kept; 'message' says why.

Input Schema

NameRequiredDescriptionDefault
modulesNoModule names to probe (e.g. ['os', 'runtimes']). Omit to probe all enabled modules.
instance_idYesInstance ID or name. '<account>/<name>' picks the server of one provider account; custom servers are 'custom/<name>'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.28.0
    • changedInput schema / properties / instance_id / description
      Previous value: -"Instance ID, name, or custom-server name."New value: +"Instance ID or name. '<account>/<name>' picks the server of one provider account; custom servers are 'custom/<name>'."
  2. Addedv2.24.0
  3. Removedv2.23.8
  4. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses SSH probing, local-cache writes, preservation of stored memory on failed SSH/host-key paths, and the meaning of specific failure reason codes.

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?

The description is front-loaded with purpose and usage, then provides return-shape and failure-mode detail because no output schema exists. The extra length is justified by operational value rather than repetition.

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?

Given no annotations and no output schema, the description supplies enough context to call the tool correctly, interpret its JSON result, and respond to the main failure modes. Nothing critical is missing for an agent selecting and invoking it.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already documented. The description adds context about probing all enabled modules but does not materially extend the per-parameter semantics beyond what the schema already says.

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?

The description states a specific verb and resource: build server memory from scratch by probing enabled modules over SSH and writing results to the local cache. It clearly distinguishes this from get_server_memory by tying invocation to missing memory or a desired fresh scan.

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?

It gives a clear trigger: call when get_server_memory returns code='missing', or when a fresh full scan is wanted. It does not explicitly contrast with refresh_server_memory, so the sibling routing is strong but not fully exhaustive.

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