SchemaSmith Documentation
Modification Tools
9 tools for controlled schema modifications with confirmation workflows.
9 tools for controlled schema modifications with confirmation workflows.
Ask Forge Tier 3 tools can modify your schema JSON files directly. They apply changes, rename objects, create new structures, and update configuration — but every operation requires explicit confirmation before executing.
These tools modify local schema files only. They do not touch live databases. To deploy changes to a database, use the Tier 4 external tools after making your modifications.
Tier 3 tools require the Operator trust level or higher. Confirmation is required by default, controlled by the confirmTier3 setting. They include all Tier 1 and Tier 2 capabilities.
Apply changes to schema JSON files — add columns, modify constraints, create tables, rename objects, and write generated schemas.
apply-change
MCP: forge_apply_change
Modifies schema JSON files to apply a specific change. This is the general-purpose modification tool — it can add columns, change data types, modify constraints, update indexes, manage foreign keys, and alter any other schema property.
Requires an active template context. The --definition parameter accepts a JSON object whose structure depends on the --change-type. Before applying, the tool shows you exactly what will change.
Key parameters:
--change-type (required) — Type of change: add_column, modify_column, remove_column, add_index, modify_index, remove_index, add_fk, modify_fk, remove_fk, add_check, modify_check, remove_check, and more--table (required) — Target table name--definition (required) — JSON definition of the changeExample:
ask-forge apply-change --change-type add_column \
--table Customers \
--definition '{"Name":"[Email]","DataType":"nvarchar(255)","IsNullable":false}'Returns: Diff preview of the change, then the updated schema file after confirmation.
create-table
MCP: forge_create_table
Creates a new table definition with platform-correct conventions. Automatically generates a primary key column, infers the PK naming pattern and data type from existing tables in the template, and applies platform naming conventions (PascalCase for MSSQL, snake_case for PostgreSQL).
Requires an active template context. When --columns is omitted, the tool creates a table with only an auto-generated primary key column.
Key parameters:
--table (required) — Table name (bare name without identifier wrapping)--schema — Schema name (defaults to platform default: dbo, public, or database name)--columns — JSON array of column definitions with name, type, nullable, and pk propertiesExample:
ask-forge create-table --table Orders --schema dbo \
--columns '[{"name":"OrderDate","type":"datetime2"},{"name":"Total","type":"decimal(18,2)","nullable":false}]'Returns: Preview of the new table definition, then the created schema file after confirmation.
rename-column
MCP: forge_rename_column
Renames a column with full cascade through all dependent objects — indexes, foreign keys, check constraints, statistics, and full-text indexes. Sets the column's OldName property for SchemaQuench deployment tracking.
The tool also scans script folders for references to the old column name and reports affected files. Script files are not modified automatically; they must be updated manually.
Key parameters:
--table (required) — Target table name--column (required) — Current column name--new-name (required) — New column nameExample:
ask-forge rename-column --table Customers \
--column Email --new-name EmailAddressReturns: List of all affected objects and script references, then the updated schema after confirmation.
rename-table
MCP: forge_rename_table
Renames a table with cascade through FK references in other tables, naming pattern suggestions, and script scanning. Sets OldName on the table JSON, renames the file on disk, and updates all cross-table foreign key references automatically.
Detects dependent object names that contain the old table name (indexes, FKs, check constraints, statistics) and suggests renames. Script file references are reported but not auto-applied.
Key parameters:
--table (required) — Current table name--new-name (required) — New table nameExample:
ask-forge rename-table --table Customer --new-name ClientReturns: List of all affected files, FK references, and naming suggestions, then the updated schema after confirmation.
apply-generated-schema
MCP: forge_apply_generated_schema
Writes generated schema tables to the template directory as JSON files. Takes the JSON output from the Tier 2 generate-schema tool and saves individual table files as {schema}.{tableName}.json.
Bridges the gap between Tier 2 generation and Tier 3 modification — generate a schema design first, review it, then apply it to write the files to your project.
Key parameters:
--schema (required) — GeneratedSchema JSON from generate-schema output--product-path — Target product directory (defaults to current context)--template — Target template name (defaults to current context)Example:
ask-forge apply-generated-schema \
--schema '{"Blueprint":{"Name":"OrderSystem"},...}' \
--product-path ./MyProduct --template MainReturns: List of table files to be created, then the written files after confirmation.
Create deployment packages and manage script folder structures within your project.
create-package
MCP: forge_create_package
Creates a deployment package (zip) containing schema files and scripts. Requires an active product context. The archive includes Product.json, template directories with table JSON files, and optionally script folders.
If a package with the same name already exists, the tool prompts for confirmation before overwriting.
Key parameters:
--name (required) — Package name (without .zip extension)--output-path — Directory to save the package (default: product root)--include-scripts — Include script folders (default: true)--template — Specific template to package (default: all templates)Example:
ask-forge create-package --name release-v2.1.0Returns: Preview of the package contents, then the created zip file path after confirmation.
add-folder
MCP: forge_add_folder
Creates a new script folder with QuenchSlot inference and JSON registration, or a subfolder under an existing folder. Requires an active product context.
In registered folder mode (no --parent), creates the directory and registers it in Product.json or Template.json with the appropriate QuenchSlot. The slot is inferred from the folder name when not specified — for example, "Procedures" maps to Objects, "MigrationScripts" maps to Before. In subfolder mode (--parent provided), creates a subdirectory that inherits the parent's slot.
Key parameters:
--folder (required) — Folder name to create--parent — Parent folder name for creating a subfolder--quench-slot — Deployment execution slot (inferred from name if omitted)--level — Where to register: product or templateExample:
ask-forge add-folder --folder Procedures --level productReturns: Preview of the folder creation and JSON registration, then the created directory after confirmation.
manage-tokens
MCP: forge_manage_tokens
Full CRUD management and analysis of script tokens ({{TokenName}} placeholders). Tokens are replaced with environment-specific values during SchemaQuench deployment. This tool can list, add, update, remove, scan for usage, and suggest tokenization opportunities.
Read-only actions (list, scan, suggest) do not require confirmation. Write actions (add, update, remove) require confirmation before execution. Supports special token types via value prefixes: <*Query*>, <*File*>, <*QueryFile*>, <*BinaryFile*>, and <*SpecificTable*>.
Key parameters:
--action (required) — Operation: list, add, update, remove, scan, suggest--level — Target level: product or template (required for write actions)--token-name — Token name without {{ }} (required for add, update, remove)--token-value — Token value (required for add and update)--scan-mode — token (find references) or orphans (find undefined references)Example:
ask-forge manage-tokens --action add \
--level product --token-name DatabaseName \
--token-value MyAppDBReturns: Token listing, scan results, or preview of the token change with the updated configuration after confirmation.
Every Tier 3 operation requires explicit confirmation before executing. This behavior is controlled by the confirmTier3 setting and is enabled by default. In the MCP server, the confirmation request is sent to the AI client, which prompts you to approve or reject the change. In the CLI, use --yes to skip confirmation for scripted workflows.