Skip to main content
Glama
astandrik

Local YDB MCP

by astandrik
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

local_ydb_apply_schema

Destructive

Validate or apply YDB table DDL via the official YDB JS SDK. Apply runs only after validation succeeds and confirm=true, supporting PRAGMA plus CREATE, ALTER, and DROP TABLE.

Instructions

Validate or apply YDB table DDL through the official YDB JS SDK. It accepts raw YQL DDL for PRAGMA plus CREATE TABLE, ALTER TABLE, and DROP TABLE; action=apply validates first and executes only with confirm=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoSchema operation to run. validate only checks the YQL DDL through the YDB SDK; apply validates first and executes only with confirm=true.
scriptYesYQL DDL script to validate or apply. Supports PRAGMA plus CREATE TABLE, ALTER TABLE, and DROP TABLE statements.
confirmNoMust be true to execute action=apply after SDK validation succeeds. Omit or false for validation plus plan-only output.
profileNoNamed profile from local-ydb.config.json. Defaults to config.defaultProfile.
timeoutMsNoSDK operation timeout in milliseconds. Defaults to 120000.
configPathNoAbsolute path to an explicit local-ydb config file. Missing, unreadable, oversized, or invalid explicit files fail closed instead of using defaults.
databasePathNoYDB database path for SDK validation/application. Defaults to the configured tenant root; root database paths use the static gRPC port.
maxOutputBytesNoMaximum UTF-8 bytes returned per validation/execution issue stream. Defaults to 65536.

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

TDQS

A3.9/5.0
Behavior4/5

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

The description adds value beyond the destructiveHint annotation by disclosing the safety flow: action=apply validates first and only executes when confirm=true. It also surfaces DROP TABLE as accepted input, reinforcing destructiveness. It does not discuss irreversibility or failure modes, but the annotations plus the confirm guard make the behavior clear enough.

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?

Two dense sentences front-load the core purpose and accepted syntax, then state the crucial execution guard. There is no filler, redundancy, or repetition of parameter defaults.

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 an 8-parameter destructive tool, the combination of the description, 100% schema coverage, and annotations is complete: it identifies the operation, the supported DDL set, and the validate-then-confirm execution path. The schema already covers plan-only output, config defaults, and output limits, so nothing needed for safe invocation is missing.

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 coverage is 100%, so the schema already documents all eight parameters. The description's references to action=apply, confirm=true, and accepted YQL DDL largely restate the schema text and add no new parameter-level meaning, so the baseline 3 applies.

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 states a clear action (validate or apply), a specific resource (YDB table DDL), and enumerates the accepted DDL statements (PRAGMA plus CREATE/ALTER/DROP TABLE). It does not explicitly differentiate the tool from siblings such as local_ydb_sql or local_ydb_scheme, so it stops just short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for schema DDL work and gives the validate-vs-apply execution rule, but it never says when to choose this tool over near alternatives like local_ydb_sql or when not to use it. The boundary must be inferred from the word 'DDL' and the sibling names.

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