The rollback design is the reason to pick this one: an assistant can draft an `UPDATE`, prove it parses and touches the rows it claims, and still leave the database untouched. Treat it as validation rather than protection — the credentials you supply are real, and SQL injection is explicitly left to whoever builds on top.
A containerized MCP server for MySQL with an unusual safety property: it accepts write statements but never commits them. A read query returns rows; a write query is executed inside a transaction that is rolled back, so what comes back is whether the statement is valid, not a changed database.
- `query` — run a read-only statement and get the rows back as JSON
- `test_execute` — run a write statement and get back whether it can execute, with the change rolled back
- `list_tables` — the table names in the database
- `describe_table` — a table's columns with type, nullability, key, default and extra
A reachable MySQL server and credentials for it. Put `MYSQL_HOST`, `MYSQL_PORT`, `MYSQL_USER` and `MYSQL_PASSWORD` in `~/.mcp/.env`; the client runs `ghcr.io/xiangma9712/mcp/mysql` with `--env-file` pointed at it. To reach a MySQL running on your own machine, set the host to `host.docker.internal` and pass `--add-host=host.docker.internal:host-gateway` — OrbStack supplies that automatically, but adding the flag is the reliable path. Package `mcp-mysql` at 1.0.3.
One command plus a key — docker run -i --rm --add-host=host.docker.internal:host-gateway --env-file ~/.mcp/.env ghcr.io/xiangma9712/mcp/mysql, then supply credentials