Skip to main content
Glama

Change a database design

edit_db

Changes a database design read at "base". All ops apply, or none: a refusal names the op and gives a fix. Name things as DBML does: orders, auth.users, orders.total, order_status (an enum), project; "enum:billing" when a name is taken twice. Renames carry through refs, indexes, groups, views and enum-typed columns; a drop takes what names it, and the reply says what. "@2" is what op 2 of this call made, "@2.1" its second thing. Replies with what changed, notes (renames guessed, refs dropped) and the checks: errors and warnings with a fix and a ready op, advice on what the call touched, at most 20 lines (check gives all).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "doc": "<doc>",
      "base": "<base>",
      "ops": "<ops>"
    },
    "name": "edit_db"
  }
}

Input Schema

NameRequiredDescriptionDefault
docYesThe doc's link or its code.
opsYesAt most {maxOps} edits (an op naming several things counts each), applied in order. Columns are [name, type, settings] with DBML's settings ("pk increment", "not null default: 'new'", "ref: > users.id"). {"op":"table","name":"orders","columns":[["id","bigint","pk increment"],["user_id","bigint","not null"]],"use":["timestamps"],"group":"billing","near":"users"} (also note, color #rrggbb, alias) {"op":"column","table":"orders","add":[["status","order_status","not null default: 'new'"]],"after":"user_id"} (or "move":"status" with "after" to reorder; first without it) {"op":"set","ids":["orders.total"],"props":{"type":"numeric(12,2)","not null":true,"pii":true}} (DBML settings by name; another key is a custom property; null takes one off) · {"op":"rename","id":"orders.total","to":"amount"} · {"op":"drop","ids":["orders.legacy","audit_log"]} {"op":"ref","from":"orders.user_id","to":"users.id","card":">","delete":"cascade"} (card > < - <>, ? an optional end; composite: lots.(a, b)) · {"op":"unref","from":"orders.user_id"} {"op":"enum","name":"order_status","values":["new",["paid","its note"]]} (or "add", "drop") · {"op":"index","table":"orders","cols":["user_id","created_at"],"unique":true} (also name, type, note, pk; "drop": true) {"op":"group","name":"billing","tables":["orders","payments"],"color":"#3498db"} ("add", "remove"; a table is in one group) · {"op":"partial","name":"timestamps","columns":[["created_at","timestamptz","not null default: `now()`"]]} · {"op":"view","name":"billing","groups":["billing"]} (tables, schemas, notes, all) {"op":"dep","from":["orders","payments"],"to":"revenue_daily"} (lineage; "drop": true) · {"op":"note","on":"orders.total","text":"Markdown"} (on a table, column, group, enum value or project; "name" for a sticky note) {"op":"dbml","text":"Table shifts {\n id int [pk]\n}"} (merge: each block given replaces the one of its name or is added; a table given has its columns, indexes and note as written, its missing columns dropped, its headercolor and custom settings kept unless given; "mode":"replace" for the whole design) · {"op":"sql","text":"CREATE TABLE …","dialect":"postgres"} (read as a dbml merge; foreign keys may name tables already in the design) {"op":"move","tables":["orders"],"near":"users"} (or "to": [x,y], "by": [dx,dy], "at": {"orders": [x,y]}) · {"op":"collapse","group":"billing"} · {"op":"arrange","group":"billing"} (lays them out afresh: "tables": [names], "group", or neither for the whole design; new tables are placed on their own, so arrange only when asked) (all three change the layout only, not the DBML) {"op":"ignore","rule":"money-float","on":"orders.total","why":"amounts come from a float API"} (a check's rule off on a table, column, enum or project, kept in the DBML as // dockito-ignore) · {"op":"unignore","rule":"money-float","on":"orders.total"}
baseYesThe version you read: version in get.
noteNoWhy, in a few words. Shown in History.
dryRunNoWork it out and answer, saving nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations (readOnly=false, destructive=false, openWorld=false) the description discloses atomic apply-or-none behavior, refusals that name the failing op and give a fix, rename propagation through refs/indexes/groups/views/enum-typed columns, drop cascade semantics, and the exact reply layout (changes, notes, checks, 20-line cap). destructiveHint=false is defensible for a versioned 'base' document that is not deployed, even though drop ops remove definitions. This is a lot of genuine behavioral context beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the verb and the atomicity contract, and the later sentences each cover a real behavior: naming, rename propagation, drop cascade, reference addressing, and reply content. It is dense and semicolon-heavy, requiring careful parsing, but there is little padding or repetition.

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 a complex tool (5 parameters, 100% schema coverage, many op variants, no output schema) the description explains what the reply contains, how errors are reported, how atomicity works, and that checks are summarized while check supplies the full set. Nothing essential for correct invocation appears missing, especially since the ops schema supplies detailed op shapes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters and carries the enormous ops examples. The description still adds meaning not in the schema: DBML naming forms (orders, auth.users, orders.total, order_status, project), 'enum:billing' disambiguation, '@2'/'@2.1' addressing of items produced earlier in the same call, and rename/drop propagation rules.

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?

Opens with 'Changes a database design read at "base"', a specific verb and resource. The DBML naming rules and op vocabulary make it clear this edits a database design rather than the doc/sheet/slides objects behind the other edit_* siblings. An agent can distinguish it without opening the schema.

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?

No sentence states when to choose edit_db over apply, save, check, restore or history. Usage is implied by the mutating verb, the all-or-none contract, and the aside that 'check gives all' plus the dryRun option, but there is no explicit when/when-not guidance or named alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources