Skip to main content
Glama
CyberKnightLabs

vmware-knight

by CyberKnightLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

set_drs_rule_enabled

Idempotent

Enable or disable an existing DRS rule with a preview before applying. Use it to temporarily turn off anti-affinity rules when a cluster is undersized, then re-enable when hosts return.

Instructions

[WRITE] Enable or disable an existing DRS rule - preview/confirm gated.

The day-2 toggle: anti-affinity rules often must be disabled while a cluster is temporarily too small to satisfy them, then re-enabled when hosts return. Idempotent - matching state returns a noop, no write. Names are matched exactly; ambiguous names refuse. Audited.

Returns: Preview dict (action="preview"), noop dict (action="noop"), or result dict (action="set", rule_now). Errors return "error" + hint.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNovCenter target name from config.yaml; omit to use the default target.
clusterYesExact cluster name.
confirmNoFalse (default) returns the blast radius and changes nothing. True applies it. Do not set True because the user asked earlier; they have not seen the preview yet.
enabledYesTrue enables the rule; False disables it.
rule_nameYesExact rule name (see list_drs_rules).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.12.10

TDQS

A4.5/5.0
Behavior5/5

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

Annotations say write, idempotent, non-destructive; the description adds the preview/confirm gate, noop on matching state, exact-match/ambiguous-name behavior, and audit trail. This is exactly the behavioral context an agent needs beyond the flags.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Starts with a purpose + write marker, then a short motivating scenario, then bullets for idempotency/name matching/audit and return shapes. No filler; all sentences carry information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies return variants (preview/noop/set/error) and key fields, plus safety and matching behavior. An agent can invoke it correctly without needing external lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and parameter descriptions are already strong, so the baseline applies. The description reinforces exact rule_name matching and preview/confirm behavior but does not need to explain fields the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states specific verb 'enable or disable' on 'existing DRS rule' and immediately distinguishes the tool from the create/delete/list DRS siblings. The preview/confirm gating and day-2 toggle context make its niche unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete scenario: anti-affinity rules disabled when cluster temporarily too small and re-enabled when hosts return. It does not explicitly name sibling alternatives, but 'existing rule' and 'day-2 toggle' make the boundary to create/delete obvious.

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

Deploy Server

Other Tools