[rahulcrl]

Adds update_rows and delete_rows tools so agents can modify and remove existing rows, completing the DML surface alongside insert_rows.

Design

Follows the ecosystem pattern (MongoDB MCP, Postgres MCP both gate all writes behind a single read-only/write switch): both tools register under the existing CRDB_MCP_ENABLE_WRITE_QUERIES=true gate. No new env vars.

Guardrails, all knob-free:

• Parser-validated: exactly one statement, correct statement type, length cap (same parseSingleStatement path as insert_rows).
• WHERE clause mandatory - bare UPDATE/DELETE is rejected before reaching the database.
• Nested writes hidden in a CTE, joined table expression (UPDATE ... FROM, DELETE ... USING), or expression subquery are rejected via a shared ensureNoHiddenDML helper; read-only ones pass.
• destructiveHint: true on both tools, plus idempotentHint: true on delete_rows, so MCP clients can surface accurate prompts.

RETURNING

Supported across all three DML tools (insert_rows included): a statement with a RETURNING clause routes through Query instead of Exec so the returned rows reach the agent, which Exec otherwise drops. Matters most for DELETE, where the removed rows cannot be read back afterwards.

Testing

• Rejection-table tests mirroring insert_rows_test.go: wrong statement type, missing WHERE, multi-statement, CTE-hidden DML, and bracket-subquery DML in WHERE / FROM / USING; plus valid execution, RETURNING-through-Query, and legitimate SELECT subqueries in SET/WHERE.
• Verified end-to-end against a local single-node cluster via the MCP tools: insert/update/delete each plain and with RETURNING, and the WHERE-less / hidden-DML cases correctly rejected.
• go test ./... passes.

[arjunmahishi]

Should DELETE sit behind the same gate as other writes?

delete_rows currently registers under CRDB_MCP_ENABLE_WRITE_QUERIES alongside inserts and updates. That follows the ecosystem pattern, but the blast radius differs: an unintended DELETE is irreversible row loss, while INSERT/UPDATE mistakes are often more recoverable. Some operators may want append/mutate without delete.

Worth noting for any future revisit: CRDB_MCP_ENABLE_WRITE_QUERIES does double duty — it gates tool registration (tools.go) and flips the pool out of read-only mode (db/manager.go → ReadOnly: !cfg.EnableWriteQueries). So a delete-specific gate could only be enforced at the registration layer, not the DB layer.

Not blocking — the mandatory-WHERE guard covers the worst case. Just flagging so the single-flag design is a deliberate choice.

[rahulcrl]

Should DELETE sit behind the same gate as other writes?

Thanks for the review @arjunmahishi!

Fair point, the single flag is intentional.
The CRDB_MCP_ENABLE_WRITE_QUERIES just answers "can this server write at all".
"Write but not delete" is a privilege question, so it belongs in SQL RBAC. An operator who wants append/mutate without delete grants the role SELECT/INSERT/UPDATE and no DELETE, and the database enforces that no matter which tools are registered. This follows our design recommendation to delegate authorization to the database wherever possible, and it aligns with the mongo/postgres MCPs.
For the accidental case, the mandatory WHERE and the destructiveHint is added.

I have added a note in the README (Tools section) making the RBAC path explicit, so the single-flag plus RBAC split is documented.