Skip to main content
Glama
AIops-tools

truenas-aiops

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

service_restart

Destructive

Restart a TrueNAS service, such as SMB or NFS, with dry-run preview and SSH confirmation safeguards; invalid names are refused.

Instructions

[WRITE] Restart a system service (e.g. 'smb', 'nfs'). Pass dry_run=True to preview.

Captures the prior service state for the audit record; declares no undo (a restart is not cleanly reversible).

Refuses a service name that is not present in service_list, and refuses 'ssh' unless confirm=True — SSH is the out-of-band recovery path, and bouncing it can strand whoever is working over it. Both refusals apply under dry_run too, which must report a refusal rather than preview a call that will be refused.

Args: service: TrueNAS service name (see service_list). confirm: Required (True) only to restart 'ssh'; ignored otherwise. dry_run: If True, preview without restarting. target: TrueNAS target name from config.

Input Schema

NameRequiredDescriptionDefault
targetNo
confirmNo
dry_runNo
serviceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.9.0
    • addedInput schema / properties / confirm
      Added value: +{
+  "default": false,
+  "title": "Confirm",
+  "type": "boolean"
+}
    • addedInput schema / properties / dry_run
      Added value: +{
+  "default": false,
+  "title": "Dry Run",
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

While annotations already flag destructiveHint=true and idempotentHint=false, the description adds substantial context beyond them: it captures prior state for audit, declares no undo, explains the ssh guard and its out-of-band rationale, and notes refusals hold under dry_run. This is unusually rich disclosure for a mutation tool.

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

Conciseness4/5

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

The critical constraints are front-loaded and every passage carries meaning, but the dry_run refusal sentence is somewhat wordy and the description is longer than strictly necessary. Structure and ordering are otherwise excellent.

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?

With no output schema and a destructive operation, the description supplies everything an agent needs: preconditions, the ssh special case, dry_run semantics, audit behavior, and irreversibility. Nothing material is left unstated.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry parameter meaning — and it does, documenting all four params including the conditional semantics of 'confirm' (required only for ssh, ignored otherwise) and the target's config provenance. This fully compensates for the empty schema descriptions.

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 ('Restart a system service') with concrete examples ('smb', 'nfs') and a '[WRITE]' marker. An agent can immediately distinguish this from read-oriented siblings like service_list.

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

Usage Guidelines5/5

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

It gives explicit conditions: use dry_run=True to preview, confirm=True only for restarting 'ssh', and the service name must exist in service_list. It names the discovery alternative (service_list) and states refusal behavior rather than leaving it to inference.

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