vibemk_create_host_contactgroup_rule

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

There are no annotations provided, and the description does not disclose any behavioral details beyond 'create'. It does not state whether the rule is immediately active, requires activation (e.g., via vibemk_activate_changes), whether it overwrites existing rules, or any side effects. Since annotations are absent, the description carries the full burden, and it fails to inform the agent about the tool's operational impact.

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 concise, one sentence, and front-loads the action ('Create host contact group rule'). It avoids unnecessary verbiage and directly states the primary function. While slightly terse, its brevity is appropriate for a tool whose schema already contains detailed parameter information. The structure is clean and easy to parse.

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's complexity (nested host_conditions object, optional parameters, and interaction with rulesets), the description alone lacks context about how the rule is stored, whether it is associated with a specific folder, or how conditions are evaluated. However, the schema provides some clarity about host_conditions (e.g., 'empty = all hosts'). The absence of an output schema and annotations leaves gaps, but the combination of description and schema is minimally sufficient for a basic understanding.

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 covers 100% of parameters with descriptions, providing baseline semantics for 'folder', 'comment', 'contact_groups', and 'host_conditions'. The tool description adds no extra parameter-level detail beyond what the schema already offers. However, the schema descriptions are reasonably clear (e.g., 'Conditions to match hosts (optional, empty = all hosts)'), so the description does not need to add much. The nested structure is explained adequately in the schema, meeting the baseline for high coverage.

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 clearly states the tool's purpose: to create a host contact group rule that assigns contact groups to hosts based on conditions. It specifies the exact action (create) and the resource (host contact group rule), and the phrase 'based on conditions' distinguishes it from simpler contact group creation. Among sibling tools, this one is clearly identified by its name and description for assigning contact groups to hosts, unlike vibemk_create_host_hostgroup_rule for host groups or generic rule creation tools.

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 no explicit guidance on when to use this tool versus alternatives such as vibemk_create_rule, vibemk_create_host_hostgroup_rule, or vibemk_update_rule. It does not mention scenarios where this is the preferred choice or that it creates a rule in the Checkmk ruleset system. The only implicit hint is the name, which is insufficient for an agent deciding between similar rule-creation tools.

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