unit_enable_toolEnable a systemd unit to start automatically on boot, ensuring required services launch at startup. Use when configuring units to persist across reboots.
Enable a unit to start on boot.
| Name | Required | Description | Default |
|---|---|---|---|
| unit_name | Yes | Systemd unit name |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely states the intended effect ('start on boot') but does not disclose what enabling actually changes (e.g., creating symlinks in systemd), whether the operation is idempotent, whether root privileges are required, or what happens if the unit is already enabled. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. It is appropriately front-loaded and every word earns its place. The lack of extra sentences does not hurt conciseness, though other dimensions penalize the missing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one fully documented parameter and no annotations, the description is overly minimal. It omits behavioral details, prerequisites, and any relationship to the many sibling systemd tools. The presence of an output schema does not compensate for missing usage guidance and behavioral transparency. A complete definition for this mutation tool should mention idempotency, persistence, and how it differs from starting a unit immediately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: 'unit_name' is documented as 'Systemd unit name'. The description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 applies. No further enrichment is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Enable a unit to start on boot.' This distinguishes it from siblings like unit_start_tool (immediate start) and unit_disable_tool (disable boot start). It is specific but does not explicitly name the sibling distinctions, so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of when enabling is appropriate, no exclusions, and no reference to related tools such as unit_start_tool for immediate start or unit_disable_tool for reverting. The agent is left to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.