local_ydb_apply_auth_hardening

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

The description contradicts the destructiveness annotation. While annotations mark destructiveHint as false, the description states 'immutable mismatches require destroy followed by bootstrap', indicating a destructive step. This is a direct contradiction. Additionally, the description provides rich detail about rollback and verification, but the contradiction dominates and warrants a score of 1 per the rubric.

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, dense sentence (albeit with semicolons) that packs multiple clauses about preflight, immutable mismatches, restart, dynamic node recreation, verification, and rollback. It is verbose and hard to parse, lacking sentence breaks and clear logical structure. It front-loads the core action but loses clarity due to length.

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 complexity of the operation, the description covers many aspects: preflight, node restart, recreation, verification, rollback, and plan-only mode. However, it omits what 'hardened' means, how metadata verification works, and the exact return value (since no output schema exists). The destructive contradiction further complicates the completeness assessment. It is adequate but has gaps.

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 covers 100% of parameters with descriptions. The description adds a small amount of context for confirm by explaining the plan-only behavior, but this is already in the schema. Profile, configPath, and configHostPath are not elaborated beyond schema descriptions. Baseline 3 is appropriate given high schema 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 apply a reviewed hardened YDB config file after preflight checks, followed by restart and recreation of nodes. The verb 'apply' and the resource 'hardened YDB config file' are explicit, and it distinguishes itself from sibling tools like prepare_auth_config or write_dynamic_auth_config by focusing on the actual application process.

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 explicit guidance: 'Use only after preparing and reviewing the config' and 'only after a full check-only static profile... succeeds'. It also implies a plan-first workflow by stating 'without confirm=true this returns the preflight/apply/recreate plan only', giving clear context for safe usage. It does not name specific alternative tools, but the 'only after' phrasing makes the intended sequence clear.

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