Skip to main content
Glama
astandrik

Local YDB MCP

by astandrik
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

local_ydb_restore_tenant

Destructive

Restore a YDB tenant from a selected dump into the configured destination path, with optional post-restore verification via count queries and scheme describes. Set confirm=true to execute; omit to preview the plan without writing data.

Instructions

Restore the configured tenant or destination path from a dump under profile.dumpHostPath, with optional post-restore scheme describe and bounded count-query verification. Use after bootstrap or rebuild when the target tenant is ready; without confirm=true this returns the restore plan and does not write data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoDestination directory path for YDB tools restore -p, relative to the configured tenant. Defaults to . for tenant root.
confirmNoMust be true to restore the tenant from the selected dump. Omit or false for plan-only output.
profileNoNamed profile from local-ydb.config.json. Defaults to config.defaultProfile.
dumpNameYesDump directory name under profile.dumpHostPath.
configPathNoAbsolute path to an explicit local-ydb config file. Missing, unreadable, oversized, or invalid explicit files fail closed instead of using defaults.
countQueriesNoOptional bounded whole-table SELECT COUNT(*) or COUNT(1) queries to verify restored data after the restore command.
describePathsNoOptional tenant-relative paths to verify with scheme describe after the restore command.

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. Changed3 schema fields changedv0.1.11
    • addedInput schema / properties / countQueries
      Added value: +{
+  "description": "Optional bounded whole-table SELECT COUNT(*) or COUNT(1) queries to verify restored data after the restore command.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "label": {
+        "description": "Optional label used in verification output for this count query.",
+        "type": "string"
+      },
+      "query": {
+        "description": "Bounded whole-table count query to run after restore, for example SELECT COUNT(*) FROM `tenant-relative/path`;. Must be a single statement using COUNT(*) or COUNT(1) and at most 4096 UTF-8 bytes.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "query"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / describePaths
      Added value: +{
+  "description": "Optional tenant-relative paths to verify with scheme describe after the restore command.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / path
      Added value: +{
+  "description": "Destination directory path for YDB tools restore -p, relative to the configured tenant. Defaults to . for tenant root.",
+  "type": "string"
+}
  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."
    • addedInput schema / properties / confirm / description
      Added value: +"Must be true to restore the tenant from the selected dump. 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.2/5.0
Behavior4/5

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

The description adds meaningful behavior beyond annotations: it discloses that confirm=false produces a plan-only dry run with no data writes, and that post-restore scheme describe and count-query verification may run. The destructiveHint annotation is consistent with the restore semantics, and the description clarifies the safe pre-confirm mode.

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?

The description is compact and front-loaded: the first sentence states the core operation, source, and optional verification; the second sentence covers usage timing and the critical plan-only behavior. Every clause earns its place with no redundant wording.

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

Completeness4/5

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

For a destructive tool with no output schema and seven parameters, the description covers the essential execution model: restore source, destination scope, confirm gating, usage timing, and optional verification. It does not detail return shapes beyond the plan-only case, but parameter schemas handle most other details.

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 description coverage is 100%, so the input schema already documents all seven parameters, including confirm, path, dumpName, profile, configPath, countQueries, and describePaths. The description does not add substantial parameter-specific meaning beyond what the schema provides, so the baseline score applies.

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 description opens with a specific verb and resource ('Restore the configured tenant or destination path from a dump'), and further specifies the source location under profile.dumpHostPath. It clearly distinguishes this restore operation from the many sibling local_ydb tools, especially dump/create/bootstrap operations.

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 a clear usage context: 'Use after bootstrap or rebuild when the target tenant is ready.' It also explains the critical confirm behavior, mentioning that omitting confirm=true returns a plan without writing. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide selection.

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