Skip to main content
Glama
astandrik

Local YDB MCP

by astandrik
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

local_ydb_add_dynamic_nodes

Adds additional dynamic tenant nodes beyond the configured node count, with per-node image and port validation. Use plan mode to preview, confirm to execute.

Instructions

Add one-off dynamic tenant nodes beyond the declarative profile.dynamicNodeCount topology, one at a time. By default the first suffix is dynamicNodeCount + 1; an explicit startIndex must be greater than dynamicNodeCount, and port overrides remain available. Every planned name must be distinct from the static container and all configured plus one-off ports must be valid and unique in the shared network namespace. After each image-presence check, it repeats the full check-only static compatibility preflight, including the current image ID, immediately before each node start; a mismatch stops that node and all later nodes and requires destroy followed by bootstrap. Each dynamic container is created but not started until its resolved image ID matches the static container, closing a concurrent named-tag refresh race. Without confirm=true it returns container/port plans; with confirm=true each node must have a stable running exact Docker container and its IC port in viewer/json nodelist before tenant metadata is checked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoNumber of additional dynamic nodes to add. Defaults to 1.
confirmNoMust be true to execute planned commands. 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.
startIndexNoSuffix for the first added container. It must be greater than profile.dynamicNodeCount. Defaults to profile.dynamicNodeCount + 1, producing <dynamicContainer>-<dynamicNodeCount + 1>.
icPortStartNoInterconnect port for the first added node. Defaults to profile.dynamicIc + startIndex - 1.
grpcPortStartNogRPC port for the first added node. Defaults to profile.dynamicGrpc + startIndex - 1.
monitoringPortStartNoMonitoring port for the first added node. Defaults to profile.dynamicMonitoring + startIndex - 1.

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. Changed1 schema field changedv0.1.18
    • changedInput schema / properties / startIndex / description
      Previous value: -"Suffix for the first added container. Defaults to 2, producing <dynamicContainer>-2."New value: +"Suffix for the first added container. It must be greater than profile.dynamicNodeCount. Defaults to profile.dynamicNodeCount + 1, producing <dynamicContainer>-<dynamicNodeCount + 1>."
  3. Addedv0.1.13
  4. Removedv0.1.12
  5. Addedv0.1.5
  6. Removedv0.1.4
  7. 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."
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true to execute commands. Omit or false for plan-only output."New value: +"Must be true to execute planned commands. 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."
  8. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Description carries substantial behavioral detail beyond annotations: the repeated static-compatibility preflight before each node start, the failure mode ('a mismatch stops that node and all later nodes and requires destroy followed by bootstrap'), the race-closing create-but-don't-start behavior, and the confirm-mode verification criterion. ReadOnlyHint=false is consistent with 'Add'; no contradiction.

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?

Dense but every sentence earns its place: purpose, indexing rules, naming/port invariants, preflight sequencing, race mitigation, and confirm semantics. The core purpose is front-loaded and there is zero filler given the tool's genuine complexity.

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 high-complexity tool with 8 parameters and no output schema, the description covers both operational modes (plan output vs confirmed execution), preconditions, failure handling, and post-condition verification. Nothing an agent needs to call it correctly or interpret its outcome is left undisclosed.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter constraints the schema lacks: 'startIndex must be greater than dynamicNodeCount', the default suffix formula dynamicNodeCount + 1, port override availability, and the uniqueness requirement across 'all configured plus one-off ports'. This adds real meaning beyond the individual property descriptions.

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?

The first sentence states a specific verb+resource+scope: 'Add one-off dynamic tenant nodes beyond the declarative profile.dynamicNodeCount topology, one at a time.' This immediately distinguishes it from removal (local_ydb_remove_dynamic_nodes), single-start (local_ydb_start_dynamic_node), and declarative topology management, no schema inspection needed.

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?

The description gives clear context for when this tool applies — one-off additions 'beyond the declarative profile.dynamicNodeCount topology' — and distinguishes plan-only (omit confirm) from execution (confirm=true) usage. It does not explicitly name sibling tools or state when-not-to-use conditions, so it stops short of a 5.

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