Skip to main content
Glama
astandrik

Local YDB MCP

by astandrik
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

local_ydb_apply_auth_hardening

Apply a reviewed hardened YDB configuration only after preflight compatibility checks pass, then restart static and recreate dynamic nodes. Use confirm=true to execute; otherwise returns the plan.

Instructions

Apply a reviewed hardened YDB config file only after a full check-only static profile and configured-binding compatibility preflight succeeds before any config or container mutation; immutable mismatches require destroy followed by bootstrap. It then restarts the static node and recreates and verifies every configured dynamic node in index order even when no dynamic-node token file is configured. Exact-container running stability and IC registration must both pass before metadata verification, and rollback uses restart or bootstrap reconciliation after restoring the static config. Use only after preparing and reviewing the config; without confirm=true this returns the preflight/apply/recreate plan only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoMust be true to apply the auth hardening config and restart local-ydb. Omit or false for plan-only output.
profileNoNamed profile from local-ydb.config.json. Defaults to config.defaultProfile.
configPathNoAbsolute path to an explicit local-ydb config file. Missing, unreadable, oversized, or invalid explicit files fail closed instead of using defaults.
configHostPathNoReviewed config.yaml path on the selected target host. Defaults to profile.authConfigPath when present.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.21
    • changedInput schema / properties / configPath / description
      Previous value: -"Explicit local-ydb config file path to load for this tool call. Useful when the MCP server should pick up a different config without restart."New value: +"Absolute path to an explicit local-ydb config file. Missing, unreadable, oversized, or invalid explicit files fail closed instead of using defaults."
    • addedInput schema / properties / configPath / minLength
      Added value: +1
  2. Addedv0.1.12
  3. Removedv0.1.12
  4. Addedv0.1.5
  5. Removedv0.1.4
  6. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / configPath / description
      Added value: +"Explicit local-ydb config file path to load for this tool call. Useful when the MCP server should pick up a different config without restart."
    • addedInput schema / properties / confirm / description
      Added value: +"Must be true to apply the auth hardening config and restart local-ydb. Omit or false for plan-only output."
    • addedInput schema / properties / profile / description
      Added value: +"Named profile from local-ydb.config.json. Defaults to config.defaultProfile."
  7. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

The description goes well beyond the annotations by detailing the exact sequence: preflight, static node restart, dynamic node recreation in index order, stability/IC registration gates, metadata verification, and rollback via restart or bootstrap. It also discloses the destroy-bootstrap requirement for immutable mismatches and the no-token-file behavior. Nothing in this narrative contradicts readOnlyHint=false or destructiveHint=false.

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

Conciseness3/5

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

The first sentence is a dense run-on that packs preconditions, mutation gating, and immutable mismatch handling into one long clause. It is front-loaded and information-dense, but could be broken into clearer separate sentences for easier agent parsing.

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?

For a complex mutation tool with no output schema, this is highly complete: preflight, plan-only behavior, mutation steps, verification requirements, and rollback are all covered. It also notes fail-closed behavior for invalid explicit configs and steps for dynamic nodes even without token files.

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?

Input schema coverage is 100%, so the schema already documents all four parameters well. The description reinforces confirm's plan-vs-apply semantics, but does not add new parameter-specific meaning beyond the schema.

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

Purpose4/5

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

The description opens with a specific action ('Apply a reviewed hardened YDB config file') and names the affected resources (static node, dynamic nodes), so its purpose is unmistakable. It does not explicitly name sibling tools such as local_ydb_apply_schema or local_ydb_prepare_auth_config, so differentiation is implied rather than explicit.

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?

Clear preconditions are given: a full check-only static profile and configured-binding compatibility preflight must pass before any mutation, and the config must be prepared and reviewed first. It also explains the plan-only behavior when confirm=true is omitted. It does not name alternatives or state when this tool should NOT be used relative to siblings.

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