There's a security reminder that comes up constantly in MCP database discussions: don't give agents write access to production databases. It's good advice. But it sidesteps the more interesting question what does responsible write access actually look like when you need agents to do useful things like run migrations, apply schema changes, or execute rollbacks?
This talk digs into the protocol-level problem. Database operations have blast radii that most MCP tool designs weren't built for. A dropped column isn't like a failed API call, it's potentially irreversible, it can reflect across the services, and the recovery window is measured in seconds. Standard MCP error handling, elicitation flows, and permission models weren't designed with this in mind.

I'll walk through what I've run into working on DB DevOps at Harness where the standard MCP primitives hold up, where they fall short, and what patterns we've found that actually work. Think scoped tool exposure by environment, migration dry-run as a first-class MCP operation, and coordinated rollback that spans both app and schema.