patch_schema

com.rationalbloks/mcp · Verify this server

Change PART of a project's schema (saves to database, does NOT deploy). Send only the change. The server applies it to the saved schema, in order and all together, and keeps every table and field it does not touch — including their identity, so a rename stays a rename and the column keeps its data. OPERATIONS (each one small object, applied in the order given): • {"op": "add_table", "table": "clocks", "definition": {...}} new table, same FLAT rules as create_project • {"op": "drop_table", "table": "clocks"} • {"op": "rename_table", "table": "clocks", "to": "timers"} • {"op": "add_field", "table": "assets", "field": "serial", "definition": {"type": "string", "max_length": 64}} • {"op": "drop_field", "table": "parameters", "field": "is_clock"} • {"op": "rename_field", "table": "parameters", "field": "is_clock", "to": "clock_kind"} • {"op": "set_field", "table": "assets", "field": "name", "properties": {"max_length": 300}} merges; a property set to null is removed • {"op": "set_table", "table": "assets", "properties": {"__audit__": true}} __policy__, __constraints__, __audit__, __admin_write__ ALL OR NOTHING: an operation that cannot be applied — a table or field that is not there, a name already taken, a schema the deploy would refuse — refuses the whole patch, naming the operation, and nothing is saved. EVERY ANSWER IS A DIFF: 'applied' (what each operation did), 'diff' (every changed property by path), 'summary' and 'plan' (the migration a deploy would then run), and 'version' (the schema's version after the change). You never need to read the whole schema back to see what you did. WORKFLOW: 1. get_schema with tables/fields to read the part you are changing (its 'version' is the whole schema's) 2. patch_schema with dry_run=true: check 'diff' and 'plan' 3. patch_schema with the same operations (pass expected_version to be refused if someone else saved meanwhile) 4. deploy_staging (confirm_destructive=true when the plan drops data), then get_job_status