Skip to main content
Glama
Knuckles-Team

Systems Manager

by Knuckles-Team
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Sm System Operations

sm_system_operations

Manage packages, apply updates, and monitor system health: install applications, clean caches, check uptime, and reboot hosts—all through one action-driven tool.

Instructions

System operations for managing packages, system health, and updates

Input Schema

NameRequiredDescriptionDefault
actionYesAction to perform. Must be one of: 'install_applications', 'update', 'reboot', 'clean', 'optimize', 'install_python_modules', 'get_os_statistics', 'get_hardware_statistics', 'search_package', 'get_package_info', 'list_installed_packages', 'list_upgradable_packages', 'system_health_check', 'get_uptime', 'list_env_vars', 'get_env_var', 'clean_temp_files', 'clean_package_cache', 'list_windows_features', 'enable_windows_features', 'disable_windows_features', 'add_repository', 'install_local_package'
env_varNoEnvironment variable name
packageNoSingle package name
packagesNoList of applications/packages
file_pathNoPath to local package file
repositoryNoRepository URL or name
allow_on_k8sNoOverride: allow 'update' or 'reboot' to proceed even if this host is detected as a live Kubernetes (RKE2) node. Prefer the universal-skills `k8s-node-rolling-update` workflow instead.
feature_nameNoWindows feature name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.5

TDQS

C2.5/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden, yet it does not disclose that actions include destructive or disruptive operations such as reboot, clean, update, and package installation. It also omits permission requirements, side effects, and the Kubernetes-node safety override that appears only in the schema.

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

Conciseness3/5

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

The description is a single concise sentence with no wasted words, but it is under-specified for a 23-action tool. Brevity is appropriate in form, but the sentence does not carry enough structural information to support correct tool selection.

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

Completeness2/5

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

For a complex multi-action tool with no annotations and no output schema, the description is far too thin. It does not explain action groups, read-versus-write behavior, destructive risks, or prerequisites needed to invoke the tool correctly.

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 the action enum and all optional parameters are already documented in the schema. The description adds no parameter meaning beyond what the schema provides, which meets the baseline for fully covered schemas.

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

Purpose3/5

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

The description names broad domains (packages, system health, updates), but it does not clearly define the tool as a multi-action dispatcher or distinguish its scope from specialized siblings like sm_service_operations or health_check. It is more specific than a tautology yet still too vague for an agent to confidently select this tool over alternatives.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus the many specialized system-operation siblings. There are no exclusions, prerequisites, or routing hints despite the tool's broad action set.

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