set_hypr_option

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them: changes are non-persistent and reset on reload, which is exactly the behavioral trait an agent needs before mutating compositor state. It stops short of saying whether invalid options error out.

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 front-loaded sentence with the key caveat parenthesized immediately after the action. No filler, nothing to trim.

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 2-param generic setter with no output schema, the critical missing piece is what makes a valid option/value pair and what happens on failure - neither the schema nor the description covers it. Annotations plus the non-persistence note make it workable but not complete.

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 coverage is 100%, but the schema's own descriptions ('Option name', 'Value to set') are near-vacuous, so the description carries some burden. It says 'via keyword', hinting at the expected format, but supplies no example option names or value syntax. 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?

States a specific verb ('Set') and resource ('runtime Hyprland config option') plus the mechanism ('via keyword'). It is clearly distinguishable from get_hypr_option, though it never names that sibling explicitly.

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 parenthetical implies the runtime/non-persistent use case, which is genuine usage context, but it never states when to prefer get_hypr_option, hypr_reload, or editing config files, and gives no prerequisites (e.g., that the option name must be a valid Hyprland keyword).

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