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

With no annotations, the description carries the full burden of behavioral disclosure. It clarifies the core action and return value, but doesn't mention potential side effects, whether it affects running units, or whether elevated privileges are required. Useful but incomplete.

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 compact and front-loaded, with the core action in the first sentence. The return note is minimal and the whole definition has no fluff or redundant elaboration.

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?

For a zero-parameter, no-annotation tool with an output schema, the description is complete enough for correct selection and invocation. The systemctl equivalence provides additional real-world context that makes the tool self-contained.

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?

The tool accepts zero parameters, so there is nothing for the description to clarify. The baseline of 4 for no-parameter tools is appropriate here.

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 specific verb and resource: 'Reload systemd's unit file cache', and anchors it with the well-known equivalence 'systemctl daemon-reload'. This makes the tool's scope clear and distinguishes it from sibling unit-level tools like unit_reload_tool, even without naming them.

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 about when to use this tool versus alternatives. It doesn't mention the common use case of running it after unit files are added, modified, or removed, nor does it contrast with unit_reload_tool or unit_* management tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The readOnlyHint annotation already tells the agent this is a safe read, so the description's remaining job is small. The only added detail is the return shape (units plus count), which largely duplicates the existing output schema; nothing is said about empty-state behavior or ordering.

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?

Two short lines, with the purpose front-loaded and the return detail after it. Every sentence carries information, and no filler is present.

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?

This is a simple, parameterless read tool with annotations and an output schema, so its description covers the essentials plus a triage cue. The only minor gap is the absence of guidance on what to do next when the list is empty or non-empty.

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?

The tool takes zero parameters, so there is nothing for the description to document; the baseline for a parameterless tool is 4. The schema is also fully closed (additionalProperties: false), leaving no ambiguity.

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?

States a specific verb (list) and a precisely scoped resource (units currently in the 'failed' state), which is more targeted than the generic unit_list_tool. It never names a sibling explicitly, so the differentiation is implicit rather than spelled out.

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?

'The first thing to check at 2AM' hints at a triage use case, giving some usage context. However, there is no explicit when-not condition and no pointer to alternatives such as unit_status_tool or journal_query_tool for follow-up diagnosis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

readOnlyHint=true already declares the safety profile, so the description isn't obliged to repeat it. It confirms the read is a fixed identity lookup with no inputs, but omits anything about whether it describes the local or a remote host, any permission requirements, or caching/freshness.

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?

Short and front-loaded, with the resource named in the first clause. The trailing 'Returns: Hostname, kernel, and OS details' largely restates the first sentence, so one line is not earning its place.

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?

For a zero-param, read-only tool with an output schema present, the description covers what is needed to select and invoke it. The only real gap is disambiguation from system_status_tool, which is a selection concern rather than a completeness one.

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?

The tool takes no parameters, which is the baseline-4 case; nothing needs explaining. The description correctly signals that the call is argument-free by listing only outputs.

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?

States a specific verb and resource ('Get host identity info') plus the concrete fields returned (hostname, kernel, OS), so an agent knows exactly what it yields. It does not differentiate itself from the closest sibling, system_status_tool, which an agent might reasonably consider an alternative.

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?

Usage is only implied by the resource name; there is no statement of when to prefer this over system_status_tool or session_list_tool, and no prerequisites or exclusions. Adequate for a zero-argument read, but inference is required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The readOnlyHint annotation already tells the agent this is a safe read operation. The description adds only a vague troubleshooting label and no behavioral context such as scope, pagination, limits, or what kind of journal is queried. It does not contradict annotations, but it adds little beyond them.

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 front-loaded sentence with little waste. The '2AM troubleshooting' phrase adds slight color but still supports the troubleshooting context; the main issue is terseness, not verbosity.

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?

The fully described schema and the existence of an output schema mean an agent can invoke the tool without more description. However, the description does not clarify the journal scope or how this diagnostic tool relates to the many sibling unit and system tools, leaving the context thin.

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%, so all seven parameters are already documented in the input schema. The description adds no parameter semantics beyond what the schema provides, which makes the baseline score of 3 appropriate.

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 specific verb and resource: 'Query the journal.' The phrase 'main 2AM troubleshooting tool' hints at its use case, but it does not explicitly distinguish this tool from sibling diagnostic tools like unit_status_tool or system_status_tool.

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?

The description implies the tool is used for troubleshooting via '2AM troubleshooting tool,' but it gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The agent must infer when journal querying is preferable to checking unit status or system status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add framing. It does add value by explaining that a non-empty result indicates a job stuck mid-transition, but says nothing about job lifecycle, staleness, or how results relate to in-flight start/stop calls.

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?

Two sentences, front-loaded with purpose and immediately followed by the diagnostic meaning. The 'Returns: List of pending jobs with count' line is slightly redundant given an output schema exists, but it is brief.

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?

With zero parameters, an output schema, and a readOnly annotation, the definition carries everything needed to invoke the tool correctly. The only real gap is the absence of routing guidance relative to the many unit_* siblings.

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?

The tool takes no parameters, so the baseline is 4. There is nothing further the description could add on this dimension.

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?

States a specific verb and resource ('List pending systemd jobs') and clarifies what that means in systemd terms ('stuck starts/stops/reloads'), which an agent could not infer from the name alone. It is distinguishable in concept from unit_list_tool and failed_units_tool, though it never names a sibling.

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?

The phrase 'reveals stuck starts/stops/reloads' implies a diagnostic use case, but the description never states when to call this instead of failed_units_tool or unit_status_tool. Usage must be inferred from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The readOnlyHint annotation already establishes this is a safe read, so the description's contribution is limited to clarifying that results are current sessions local to this host. It adds modest context but nothing about freshness, ordering, or handling of remote/SSH sessions.

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?

Front-loaded and short, with the purpose in the first clause. The trailing "Returns: List of sessions with count" duplicates information already covered by the output schema and could be dropped.

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?

With no parameters, a readOnly annotation, and an output schema present, the description covers everything an agent needs to decide and invoke correctly. Only minor gaps (scope of sessions counted) remain.

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?

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics for the description to explain.

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?

States a specific verb and resource ("List logged-in sessions") and adds scope ("who's on this box right now"), which is clearly distinct from the systemd unit/timer/journal siblings. It does not explicitly name alternatives, but the domain difference is obvious.

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?

Usage is only implied by the phrase "who's on this box right now" — an agent can infer this is for checking current interactive logins rather than history. There are no explicit when-to-use/when-not conditions or named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful context about the state values (running/degraded) and the presence of failed/job counts, but it does not go much beyond the annotation and output schema in describing behavior.

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 short, front-loaded, and contains no wasted language. It states the core purpose first and optionally lists return values in a compact form.

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?

For a simple, zero-parameter read-only status tool with an output schema, the description is largely complete. It could be slightly stronger by explicitly routing agents to failed_units_tool or list_jobs_tool when they need detailed lists rather than aggregate status.

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?

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4.

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 specific verb and resource: get overall systemd manager state, including running/degraded status and failed/job counts. It implicitly distinguishes itself from unit-level siblings like unit_status_tool and list-oriented siblings like failed_units_tool and list_jobs_tool by emphasizing overall manager state and counts rather than per-unit details or lists.

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?

Usage is implied: this is the tool for a high-level system health check. However, the description does not explicitly say when to use it instead of siblings such as failed_units_tool or list_jobs_tool when the agent needs detailed per-unit or per-job information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds that elapse times are surfaced, but omits whether timers are listed system-wide vs. per-user, whether inactive timers appear, or any pagination/ordering behavior.

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?

Two short sentences, purpose front-loaded with zero filler. The 'Returns: List of timers with count' line is slightly redundant given an output schema exists, but it is not harmful.

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?

A simple, parameterless read tool with annotations and an output schema — little burden falls on the description, and what it claims is sufficient to call it correctly. Minor gaps (scope of listing, active vs. inactive) keep it below 5.

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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. Nothing in the description misleads about inputs.

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?

States a specific verb and resource: lists systemd timers, plus the notable detail that next and last elapse times are included. It differentiates from unit_list_tool only implicitly (timers vs. generic units), so it stops short of the sibling-level precision a 5 requires.

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?

Usage is only implied by the resource name — an agent can infer you call this when inspecting scheduled timers. There is no explicit when-to-use vs. unit_list_tool or when-not guidance, and no prerequisites noted.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add the useful side-effect that operations on protected units are refused. However, it omits other common behavioral traits, such as whether a currently running unit is unaffected, whether root privileges are required, or whether the operation is reversible via enable. The protected-list disclosure earns a pass, but the description could be more transparent.

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 two sentences with zero filler. The core action is stated first, and the protected-list exception is appended as a necessary behavioral note. Every sentence contributes; this is an example of appropriately concise and well-structured text.

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?

For a single-parameter tool with an output schema, the description is largely adequate: it states what the tool does and the key exception. However, it does not mention that disabling a unit does not stop it if it is currently running, which is a common misunderstanding and could lead to incorrect tool selection. Given the low complexity, the description is functional but not fully complete for an agent unfamiliar with systemd.

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% (the only parameter is documented as 'Systemd unit name'), so the description adds no extra semantics. That is acceptable per the baseline rule, though the description does not clarify whether the unit name should include the .service suffix or other common format details.

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 'Disable a unit from starting on boot' clearly states the specific action (disable) and resource (unit) and scope (at boot), which distinguishes it from tools like unit_start_tool or unit_stop_tool. It does not explicitly contrast with unit_mask_tool or unit_enable_tool, but the boot-time focus is enough to make the primary purpose unambiguous.

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 choose this tool over siblings such as unit_mask_tool, unit_stop_tool, or unit_enable_tool. The only additional sentence mentions a refusal condition (protected list) but does not help an agent decide between alternatives. This is a clear gap for a tool with many closely related siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does 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.

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

With no annotations, the description carries the full burden and does well: it discloses the multi-step destructive behavior, backup, optional masking, protected-list refusal, and best-effort semantics for stop/disable. It does not mention permission requirements or what 'back up' entails, which would strengthen transparency for a destructive operation, but it is far above the minimum.

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 two sentences with no fluff. The main action is front-loaded, and the caveats (protected list, best-effort behavior) are placed immediately after. Each sentence earns its place and there is no redundant restatement of the title or schema.

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?

For a destructive multi-step tool, the description covers the essential context: what will happen, when it will be refused, and when partial failures do not block removal. An output schema is present, so return values need not be described. A bit more detail about backup location or required privileges would make it fully complete for an agent, but the current description is adequate.

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%, so the baseline is 3. The description's 'optionally mask' matches the mask parameter and 'remove its file' maps to unit_name, but it adds little meaning beyond what the schema already explains. No extra parameter-level guidance is provided.

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 opens with a specific verb and resource: 'Decommission a unit', then lists the exact operations (stop, disable, optionally mask, back up, remove file). This clearly distinguishes the tool from siblings like unit_stop_tool, unit_disable_tool, and unit_mask_tool by marking it as the full removal/decommission operation. It also adds a scope constraint (protected-list refusal) that makes the tool's purpose more precise.

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?

The description gives a clear when-to-use signal: decommissioning a unit, as opposed to merely stopping or disabling it. It also states an explicit when-not: 'Refused for units on the protected list.' However, it does not explicitly name alternative sibling tools such as unit_stop_tool for stop-only scenarios, so it stops just short of the highest level of routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool overwrites files with a backup and runs daemon-reload after writing, which are critical side effects. It does not describe error cases or permission requirements, but the disclosed behaviors are the most important for safe invocation.

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 compact and well-structured: it states the core action first, then the safety behavior, then the operational prerequisite and post-write action. Every sentence adds necessary information without padding.

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?

The description covers the main operational context: what the tool does, overwrite/backup behavior, the bind-mount requirement, and daemon-reload side effect. Since an output schema exists, return-value documentation is not required here. It is complete enough for an agent to invoke the tool correctly, though it could mention behavior when the unit already exists.

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?

The input schema already provides 100% parameter coverage with clear descriptions for all four parameters. The tool description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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 names a specific verb ('Write') and resource ('unit file') and states its purpose ('setting up a service'). It also signals overwrite behavior with backup, which helps distinguish it from read-only unit tools and unit_file_remove_tool.

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?

The description gives clear context: it is the tool for writing unit files as part of service setup, and it states an important environmental prerequisite (bind-mounted unit directory). It does not explicitly name alternatives or when-not-to-use cases, but the context is sufficient for an agent to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

readOnlyHint=true already tells the agent this is a safe read, so the annotation carries the safety profile. The description adds no behavioral context of its own — nothing about ordering, result volume, pagination, or how the default active/failed filtering behaves, which is the sort of nuance annotations do not cover.

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?

A single four-word sentence, front-loaded and free of waste. It is efficient but borders on under-specification rather than being genuinely well-structured for a tool with meaningful filtering options.

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?

An output schema and annotations cover return shape and safety, but the description leaves the core selection problem unsolved: with siblings like failed_units_tool and timer_list_tool, an agent needs at least a hint about scope (all units vs. failed vs. timers). That routing context is entirely missing.

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%; all three parameters (mode, pattern, all_units) are documented with defaults and examples in the schema itself. The description adds no additional parameter meaning, so the baseline 3 applies.

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?

"List systemd units" states a clear verb (list) and resource (systemd units), so the basic operation is unambiguous. However, it makes no attempt to distinguish this from siblings like failed_units_tool, timer_list_tool, or unit_status_tool, which an agent must disambiguate among.

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?

There is no when-to-use guidance, no mention of alternatives, and no exclusions. With 20 sibling tools including failed_units_tool and timer_list_tool, the agent gets no signal about why to pick this general lister over the specialized ones.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the behavioral disclosure burden. It states the key outcome ('cannot be started even manually') and a failure condition ('Refused for protected units'). It could additionally mention privilege requirements or reversibility, but the core behavior is clearly disclosed.

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 two short sentences with no filler. The main effect is front-loaded, and the important limitation about protected units is included efficiently.

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?

For a single-parameter tool with an output schema, the description is mostly complete: it names the action, effect, and a limitation. It omits minor operational context such as required privileges or how to reverse the operation, but the tool is simple enough that this is not a major gap.

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% and the single parameter is already described as 'Systemd unit name.' The description adds little parameter-specific meaning beyond restating that a unit is the target, so the baseline score of 3 applies.

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 uses a specific verb and resource: 'Mask a unit so it cannot be started even manually.' It clearly distinguishes this from sibling tools like unit_start_tool and unit_unmask_tool by stating the intended effect.

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?

The description implies when to use the tool: when a unit should be prevented from starting even manually. However, it does not explicitly mention alternatives such as unit_disable_tool or unit_unmask_tool, nor does it say when not to use it beyond noting protected units are refused.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the burden of behavioral disclosure. It correctly indicates the operation is non-restarting, which is a key behavioral trait. However, it does not disclose potential side effects, whether the reload is synchronous, or what happens if the unit is not running, which would be useful for an agent invoking the tool.

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, concise sentence that front-loads the action and object. Every word earns its place, and there is no redundant or vague filler.

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?

The tool is simple with one parameter and an output schema, so the description does not need to explain return values. However, given the sibling set includes unit_restart_tool and daemon_reload_tool, the description could have clarified the distinction between reloading a unit's config and reloading systemd's manager configuration. The lack of behavioral details (e.g., effect on running processes) leaves a moderate gap.

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% for the single parameter, and the description adds no additional meaning beyond the schema's 'Systemd unit name'. The description's mention of 'unit' aligns with the parameter, but it does not clarify format, validity rules, or how the unit_name is resolved, so it adds minimal value over the schema.

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 specific verb ('reload') and resource ('unit's configuration'), and the title reinforces the tool's purpose. It is clear enough to distinguish from siblings like unit_start_tool or unit_restart_tool, though it does not explicitly name a sibling or contrast itself with unit_restart_tool.

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?

The description implies when to use the tool: when a unit's configuration has changed and needs to be reloaded without a full restart. However, it does not explicitly state when not to use it or mention alternatives like unit_restart_tool or daemon_reload_tool, leaving some ambiguity for an agent deciding between reload and restart.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses one trait – refusal for protected units – but does not mention that restart is a disruptive mutating operation, any permission requirements, or that it stops and starts the unit. This is marginal beyond the verb itself.

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?

A concise two-sentence description with no filler. Both sentences carry meaning: the core action and the refusal constraint. It is appropriately front-loaded with the verb.

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?

For a single-parameter tool with an output schema, the description is minimally complete: it states the operation and one key constraint. However, it omits operational context such as the disruptive nature of restart, permission requirements, and the relationship to reload, which would help an agent use it safely without annotations.

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 covers 100% of the parameter ('Systemd unit name'), so the baseline is 3. The description adds no additional semantics such as exact-name syntax, glob support, or validation rules beyond what the schema provides.

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?

States a specific verb and resource ('Restart a unit'), which unambiguously distinguishes it from sibling tools like unit_start_tool, unit_stop_tool, and unit_reload_tool. The action is clear and not a tautology of the name.

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?

Provides no guidance on when to restart versus using a sibling such as unit_reload_tool or unit_start_tool, and no mention of prerequisites like daemon-reload after unit file changes. The only context is a refusal condition for protected units, which is a restriction, not a usage guideline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful scope by saying it returns the full property set, including dependencies, exec settings, and cgroup details. It does not cover pagination, output format beyond the property categories, or any operational constraints.

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 definition is a single efficient sentence with the operation and scope front-loaded. Every phrase contributes useful information about the returned property categories.

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?

For a simple read-only tool with one required parameter and an output schema, the description is largely complete: it states the returned data scope and aligns with the read-only annotation. The remaining gap is lack of explicit sibling differentiation from unit_status_tool.

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?

The schema has 100% description coverage and documents the single unit_name parameter clearly. The description does not add syntax or formatting details beyond what the schema already provides, so the baseline score of 3 applies.

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 gives a specific verb and resource: dump the full property set for a unit. The examples of included properties (dependencies, exec settings, cgroup) sharpen what kind of data is returned. It does not explicitly distinguish itself from the overlapping sibling unit_status_tool, so it stops short of 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?

There is no explicit guidance on when to use this tool versus unit_status_tool or unit_list_tool. The read-only inspection use case is implied by 'Dump the full property set,' but no alternatives or exclusions are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. 'Start a unit.' only states the basic action and does not describe resulting system state changes, requirement of privileges, failure behavior, or consequences of starting an already-active unit.

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 terse and free of filler, and the core action is front-loaded. However, its brevity reflects under-specification rather than a deliberately structured explanation, so it is only minimally acceptable on this dimension.

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?

The parameter schema and presence of an output schema cover basic invocation details, but this is a state-changing systemd operation with no annotations and no usage context among twenty sibling tools. The description lacks enough context for an agent to choose this tool intentionally and understand the consequences of invoking it.

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?

The schema fully documents the single parameter unit_name as 'Systemd unit name', giving 100% schema description coverage. The description adds no additional parameter semantics, so the schema baseline of 3 applies.

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 'Start a unit.' merely restates the tool name and title ('unit_start_tool', 'Unit Start Tool') without adding any detail about what a unit is, which system is affected, or how this operation differs from the many sibling unit lifecycle tools. It is a clear sentence, but it contributes no informative value beyond the title.

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?

There is no guidance about when to use this tool versus unit_stop_tool, unit_restart_tool, unit_reload_tool, or daemon_reload_tool. No preconditions, side effects, or alternative routing are mentioned, leaving the agent to infer usage solely from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds that the status is "curated" and lists the included fields, but it does not disclose additional behavioral context such as permissions, caching, or how this differs from unit_show_tool.

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, front-loaded sentence with no wasted words. It efficiently states the action and the returned status fields.

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?

With a fully documented single parameter, a readOnly annotation, and an output schema, the description is nearly complete for a simple status query. Its only notable omission is distinguishing this tool from the overlapping sibling unit_show_tool.

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%, and the single unit_name parameter is documented with an example in the schema. The description adds no parameter syntax or constraints beyond what the schema already provides, so the baseline of 3 is appropriate.

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 uses a specific verb and resource: "Get curated status for a unit," and enumerates the fields returned (active/sub/load state, PID, memory, CPU). It does not distinguish this tool from the similar sibling unit_show_tool, so it is clear but lacks sibling differentiation.

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?

The description gives no explicit guidance on when to use this tool rather than unit_show_tool, unit_list_tool, or system_status_tool. Usage is only implied by the tool name and the word "status."

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description discloses a meaningful behavioral guardrail: refusal for units on the protected list. However, with no annotations, it does not cover side effects such as process termination, whether the unit can be restarted afterward, permission requirements, or failure semantics. It is partially transparent but not complete.

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 two short sentences with zero wasted words. The core operation is front-loaded, and the protected-list caveat is placed clearly in the second sentence.

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?

For a simple one-parameter tool with an output schema, the description is minimally complete: it states the action and a key restriction. It lacks usage context and behavioral details, but the low complexity means an agent can likely call it correctly with the schema.

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%, and the single parameter is described as 'Systemd unit name.' The description adds no extra parameter-level detail, but the schema already carries the full burden, so the baseline of 3 applies.

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 specific action and resource: 'Stop a unit.' This clearly distinguishes it from obvious siblings like unit_start_tool and unit_restart_tool by the action verb. It does not explicitly call out those siblings, but the operation is unambiguous.

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?

The description gives no guidance on when to prefer stop over restart, reload, or mask, and does not mention prerequisites or consequences. The protected-list refusal is a constraint, not usage guidance, so an agent must infer the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core action but does not mention side effects (e.g., removing the mask symlink, making the unit startable again), administrative requirements, or any expected systemd behavior beyond the basic unmask operation.

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, complete sentence with no filler, front-loading the key verb and object. Every word contributes to understanding the tool's purpose.

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?

For a simple one-parameter tool with an output schema, the description is minimally viable but lacks behavioral and usage context that would help an agent handle edge cases or prerequisites. It is not fully complete, but it is not misleading either.

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% for the only parameter, unit_name, which is already described as 'Systemd unit name'. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies.

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 uses a specific verb ('Unmask') and a clear resource ('a previously masked unit'), which directly distinguishes it from sibling tools like unit_mask_tool and unit_start_tool. There is no ambiguity about what action this tool performs.

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?

The phrase 'previously masked unit' gives a clear context for when the tool is applicable, but the description does not explicitly state when to use this tool over alternatives or mention any exclusions. It relies on the name and sibling list to convey most of the usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.