sys_reboot

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 honestly discloses that the action is a write and that confirmation is required, which is valuable for a destructive operation. It does not, however, explain the impact on active sessions, approximate downtime, or the confirmation flow 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?

The entire description is one compact sentence with the core action front-loaded and the critical safety qualifier ('write — requires confirmation') placed immediately after. Every word earns its place and there is no redundant framing.

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 disruptive write operation with no annotations, no output schema, and four undocumented parameters, the description is too thin. It fails to explain the confirmation token mechanism, what user_code represents, or what happens after the reboot is triggered, leaving an agent to guess at required inputs.

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 0% and none of the four parameters (user_code, acknowledge, confirm_token, confirmation_id) are documented. The description's mention that confirmation is required hints at the confirmation-related parameters, but it does not clarify their individual meanings or which are mandatory for the tool to proceed.

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 ('Restart'), a clear resource ('the router'), and an immediacy qualifier ('immediately'), so an agent can tell what the tool does. It also flags the operation as a 'write', which distinguishes it from the many read-oriented show/sys sibling tools, though it does not explicitly name any 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?

The description provides some usage context by noting this is a write operation that 'requires confirmation', implying it should not be invoked without explicit user consent. However, it does not describe when to prefer this tool over related tools such as sys_autoreboot, nor does it list any preconditions or exclusions.

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