Local YDB MCP

@astandrik/local-ydb-mcp

Unofficial stdio MCP server for operating Docker-based local-ydb deployments.

Website: local-ydb-toolkit.ydb-qdrant.tech.

Relationship to ydb/ydb-mcp

This package is complementary to the official ydb-platform/ydb-mcp server. Use ydb/ydb-mcp for general YDB database-level tools such as ad hoc SQL queries, query explanations, directory listing, and path inspection against an existing YDB endpoint.

Use @astandrik/local-ydb-mcp when an agent needs to operate Docker-based local-ydb environments themselves: host prerequisite checks, root or tenant bootstrap, database healthcheck diagnostics, dynamic-node lifecycle, GraphShard checks, table DDL generation/validation/application for local deployments, auth hardening, storage workflows, dump/restore, and version upgrades. Its local_ydb_sql tool is deliberately narrower than ydb/ydb-mcp: it runs managed YQL only against the selected configured local-ydb profile. Mutating tools are plan-first and require confirm: true before they execute changes.

MCP Client Config

This package requires Node.js 20.19 or newer.

Inspect the installed CLI without starting the MCP server:

local-ydb-mcp --versionlocal-ydb-mcp --help

Or run the same commands through npm:

npx --yes @astandrik/local-ydb-mcp@latest --versionnpx --yes @astandrik/local-ydb-mcp@latest --help

Each flag prints to stdout and exits with code 0, without loading the toolkit config. Unknown arguments, repeated flags, and combinations of flags print a usage error to stderr and exit with code 2. Only the long --version and --help flags are supported. Start without arguments for normal MCP stdio operation; do not add these diagnostic flags to the MCP client launch configuration.

Use npx so clients can run the server without a manual checkout:

{  "mcpServers": {    "local-ydb": {      "command": "npx",      "args": ["-y", "--prefer-online", "@astandrik/local-ydb-mcp@latest"],      "env": {        "LOCAL_YDB_TOOLKIT_CONFIG": "/path/to/local-ydb.config.json"      }    }  }}

This form checks the npm registry when the MCP server starts, so clients pick up newly published versions after restarting the MCP client.

The config file is optional. If LOCAL_YDB_TOOLKIT_CONFIG is not set, the server reads local-ydb.config.json from the current working directory. A present but empty environment value is explicit and returns CONFIG_PATH_NOT_ABSOLUTE. If the implicit file is absent, the server uses a default local profile with ghcr.io/ydb-platform/local-ydb:stable-26-1-1. LOCAL_YDB_TOOLKIT_CONFIG and per-call configPath values must be absolute and must name a readable regular JSON file no larger than 1 MiB. The configured defaultProfile must name an existing profiles entry. Missing, unreadable, oversized, malformed, or schema-invalid explicit files fail closed and return a stable error code without exposing file contents, parser snippets, or the absolute path.

The named upstream default tag is mutable. Set profiles.<name>.image explicitly to control upgrades; use a digest for immutable pulls, noting that local_ydb_upgrade_version does not accept digest-pinned source profiles.

After a package update changes the implicit default, an existing stack created with the previous default will fail the profile compatibility check instead of mixing YDB images. Add the stack's current image reference to a file-backed profile before restart or bootstrap, then use local_ydb_upgrade_version for an intentional dump-and-rebuild upgrade.

Official MCP Registry metadata uses the name io.github.astandrik/local-ydb-mcp and is published from the repository root server.json after the matching npm version is available.

MCP Features

The server exposes local-ydb operation tools and static MCP prompts. Prompt templates guide stack diagnosis, root database bootstrap, tenant topology bootstrap, database diagnostics, schema generation/apply, version upgrades, auth hardening, and storage group reduction. Prompts return workflow instructions only; they do not execute commands. A prompt configPath, when supplied, must be an absolute path just like the corresponding tool argument.

Mutating tools remain plan-only unless called with confirm: true.

Tools

The server exposes 39 tools. This index is generated from the runtime tool registry; edit toolDefinitions and run npm run docs:generate to update it.

Checks

Schema

Sql

Auth

Storage

Lifecycle

Dynamic Nodes

Backup Restore

Managed SQL/YQL

local_ydb_sql uses YDB Query Service for managed YQL v1 against the selected configured local-ydb profile:

The script must be well-formed Unicode and is limited to 1,048,576 characters; lone UTF-16 surrogates are rejected before hashing or protobuf encoding. One deadline covers connection, session, preflight, and execution: timeoutMs defaults to 120,000 and is capped at 600,000. maxRows defaults to 100 and is capped at 10,000 per result set, but the first row-limit hit stops all further result capture: read-only execution is cancelled, while confirmed NoTx execution drains without capturing later output. maxOutputBytes defaults to 65,536 and is capped at 1 MiB across captured issues, plan/AST, column metadata, and complete rows; partial JSON values are never returned.

Parameters use bare names matching [A-Za-z_][A-Za-z0-9_]*. The tool sorts names and prepends deterministic DECLARE $name AS Type; statements. Recursive descriptors support primitive/Decimal, Optional, List, Tuple, Struct, and Dict types, with limits of 100 parameters, depth 16, 1,000 type nodes, 10,000 parameter value nodes, and 1 MiB of serialized values; Decimal precision is 1..35 and scale cannot exceed precision. Use JSON numbers for 32-bit integers; decimal strings for 64-bit integers, Decimal, and DyNumber, with canonical "nan", "inf", and "-inf" also accepted for Decimal; canonical base64 for binary String and Yson; well-formed Unicode for Utf8 strings and Struct field names (lone UTF-16 surrogates are rejected); native JSON for Json/JsonDocument; official ISO date/time forms with timezone values suffixed by ,<IANA zone>; ISO-8601 durations for intervals; null for empty Optional; arrays for List/Tuple; objects for Struct; and {key,value} arrays for Dict. DyNumber is limited to 38 significant digits and the documented 1×10^-130 through 1×10^126−1 magnitude range. Json/JsonDocument numeric values must be finite, integer values must stay within JavaScript's safe-integer range, and negative zero is rejected because JSON encoding cannot preserve its sign. Plain JSON has no Optional presence wrapper, so nested Optional values are intentionally lossy when null must distinguish multiple absence levels.

Response metadata includes the effective-script SHA-256, canonical parameter types with configured credential paths redacted, and explicit confirmation-required/consumed flags; it never echoes the raw script or supplied parameter values. Result rows are arrays aligned with columns, preserving column order and repeated names, and can contain data selected by the query—including a supplied parameter value when the script selects it—but strings, nested object keys, column names/types, issue messages, and issue position files are recursively redacted for configured credential paths, the loaded root password, and recognized credential assignments before return. Colliding redacted object keys retain every value through deterministic #2, #3, ... suffixes. Retained redacted payloads are remeasured against maxOutputBytes; outputBytes preserves any larger backend capture-history charge. Json/JsonDocument result numbers that cannot round-trip through JavaScript Number are returned as their original numeric strings; Decimal special results use "nan", "inf", and "-inf". Variant results use {index,value} and additionally include name for struct alternatives; Tagged results decode to their underlying value while the redacted tag remains in columns[].type. Variant and Tagged remain unsupported as parameter descriptors. Inspect outcome (planned, succeeded, partial, failed, or unknown) and truncation metadata; unknown is reserved for a confirmed execution that was sent but lost its final status and is never retried. Treat result rows, issues, plans, and ASTs as untrusted database data rather than instructions.

Response Content Format

By default, tool responses keep the current MCP shape: structuredContent is a JSON object, and the second text content block is pretty-printed JSON. To prefer TOON for the LLM-facing text block only, set:

{  "env": {    "LOCAL_YDB_MCP_CONTENT_FORMAT": "toon"  }}

Valid values are json and toon; omit the variable for the default json format. This does not change MCP JSON-RPC, tool input schemas, or structuredContent. In toon mode the server verifies that the encoded text decodes back to the same JSON data model; if not, it falls back to pretty JSON for that response text.

For a reproducible local comparison of representative response fixtures:

npm run compare:formats -w @astandrik/local-ydb-mcp

Manual agent smoke check: run the MCP server once with LOCAL_YDB_MCP_CONTENT_FORMAT=json and once with toon, then call the same tools in both sessions: local_ydb_inventory, local_ydb_status_report, local_ydb_healthcheck, local_ydb_bootstrap_root_database without confirm, local_ydb_scheme, local_ydb_generate_schema with validate=true, local_ydb_apply_schema with action=validate, local_ydb_sql for a parameterized query, standalone explain, and plan-only execute, local_ydb_permissions with a plan-only mutation, local_ydb_list_versions, and local_ydb_nodes_check. Record whether the agent extracts the same status, planned commands, risks, and next steps. Treat this as qualitative evidence; the benchmark command is the reproducible metric.

Global Install

npm install -g @astandrik/local-ydb-mcp

{  "mcpServers": {    "local-ydb": {      "command": "local-ydb-mcp",      "env": {        "LOCAL_YDB_TOOLKIT_CONFIG": "/path/to/local-ydb.config.json"      }    }  }}

local_ydb_generate_schema is the read-only structured table-DDL generator. It renders strict JSON specs for CREATE TABLE, table-level secondary indexes, ordered ALTER TABLE column/index changes, and DROP TABLE; returns the generated DDL text, script SHA-256, official YDB references, warnings, risk, and verification steps; and can validate the generated script when validate: true is supplied. It never applies DDL and uses the same 1 MiB generated-script limit as local_ydb_apply_schema. In with settings, setting names must be YQL-style identifiers, strings render as quoted YQL literals, use { "token": "ENABLED" } for bare-token settings, and use the top-level store field instead of with.STORE. Keep column names away from the reserved __ydb_ prefix, use CREATE TABLE notNull only for columns that are part of the primaryKey, use partitionByHash only with store: "column" and primary key columns, keep column-oriented primary keys NOT NULL and within the documented supported key types, keep secondary/vector indexes on row-oriented tables, use global secondary indexes without creation-time with settings, keep unique indexes synchronous, keep ALTER TABLE ADD COLUMN to name/type only, reject duplicate add/drop column/index actions in one spec, keep indexes off columns added or dropped in the same alterTable spec, provide a non-unique global: true, sync: "sync" vector index with complete vector_kmeans_tree settings, expect a warning when creating a table with a vector index because adding the index after representative data is preferred, and rely on type-aware defaults such as Utf8('x'), Uint64('1'), or Date('2026-05-27').

Mutating tools are plan-only unless called with confirm: true. local_ydb_apply_schema is the table-DDL apply path: it validates raw or generated YQL DDL through the official @ydbjs/* SDK, supports PRAGMA, CREATE TABLE, ALTER TABLE, and DROP TABLE, and applies only after validation succeeds and confirm: true is present. Responses report the script SHA-256 and capped YDB issue text without echoing the raw script or credential paths. For table creation, prefer a CMS tenant path such as /local/example; a root-only /local stack can validate DDL through the static endpoint, but YDB rejects storage-backed table creation there when the root database has no tenant storage pools.

The server includes a root-only local_ydb_bootstrap_root_database tool for starting /local with just the static node, a tenant-oriented local_ydb_bootstrap tool for GraphShard-ready dynamic-node topologies, a read-only local_ydb_list_versions tool for discovering published local-ydb image tags with numeric versions sorted newest first, background image-pull tools (local_ydb_pull_image and local_ydb_pull_status) for slow registry downloads, local_ydb_generate_schema and local_ydb_apply_schema for table DDL generation/validation/application, local_ydb_list_dumps plus dump/restore tools for tenant-wide or tenant-relative backup operations, and a high-risk local_ydb_upgrade_version tool that upgrades a file-backed profile by image preflight, dump, rebuild, restore, auth reapply, image verification, and profile-image persistence. A verified mismatch leaves the profile unchanged; unavailable final inventory after completed rebuild phases returns partial verification and persists the target image. Bind-mounted data profiles are not supported by the automatic upgrade path.

local_ydb_dump_tenant and local_ydb_restore_tenant accept path while preserving existing tenant-wide defaults. Dump path is the source object or directory for ydb tools dump -p; restore path is the destination directory for ydb tools restore -p. Use local_ydb_list_dumps before restore to choose a dumpName, and use optional describePaths plus bounded whole-table countQueries such as SELECT COUNT(*) FROM \dir/table`;` when a restore needs post-command verification.