Skip to main content
Glama
Sign In
homebutler

homebutler

by Higangssh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

doctor

Read-only

Run a read-only homelab health check to detect resource pressure, stopped containers, public ports, backup age, and notification issues, then report baseline readiness and warnings.

Instructions

Run a read-only diagnosis for resource pressure, stopped containers, public ports, backup hygiene, notifications, and report baseline readiness

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "doctor"
  }
}

Input Schema

NameRequiredDescriptionDefault
serverNoRemote server name from config (optional, runs locally if omitted; inside a container a local call is refused, because a container cannot see the machine it is on)
backup_max_age_hoursNoWarn when the latest backup is older than this many hours (default: 168)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.0
    • changedInput schema / properties / server / description
      Previous value: -"Remote server name from config (optional, runs locally if omitted)"New value: +"Remote server name from config (optional, runs locally if omitted; inside a container a local call is refused, because a container cannot see the machine it is on)"
  2. Changed1 schema field changedv0.41.0
    • changedInput schema / properties / backup_max_age_hours / type
      Previous value: -"number"New value: +"integer"
  3. Addedv0.19.0

TDQS

A3.5/5.0
Behavior3/5

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

The description's 'read-only' claim is consistent with readOnlyHint=true and destructiveHint=false, so there is no contradiction, but it adds little beyond them. It does not say how findings are surfaced (warnings vs errors vs exit status) or whether the check is expensive, which matters for a tool with no output schema. The container-refusal behavior for local calls lives in the schema, not the description.

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?

A single front-loaded sentence with the verb first and the check categories enumerated; no filler, no restatement of the name or title. Every clause earns its place by naming a covered domain.

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

Completeness3/5

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

For a composite, multi-domain diagnostic with no output schema, the definition should indicate what a run produces (a list of findings? severity levels? whether it fails hard on any issue) as well as the enumerated categories. The category list is a good start but leaves the shape of the result and the cost of the run unstated.

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 (server, backup_max_age_hours) are already well documented, including the container-refusal caveat and the 168-hour default. The description adds no parameter-level meaning beyond the schema, which is acceptable at full coverage but not value-adding.

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

Purpose4/5

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

Uses a specific verb ('Run a read-only diagnosis') and enumerates the exact check categories: resource pressure, stopped containers, public ports, backup hygiene, notifications, and report baseline readiness. An agent can tell this is a composite health-check tool rather than a single-resource query, though it never explicitly names the narrower siblings (open_ports, docker_list, processes, report) it aggregates.

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

Usage Guidelines3/5

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

The description implies the use case (a general health check before/instead of individual probes) but gives no explicit when-to-use, when-not-to-use, or routing to alternatives. With siblings like open_ports, processes, and report available, an explicit 'use this first' or 'use X for a focused check' statement would materially help selection.

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