Putting the table structure behind resources rather than a tool means a model can read the schema without it counting as a query, which keeps the exploration phase cheap and the query tool focused. The read-only transaction is a real boundary rather than a prompt instruction. The exposure to plan around is the connection string: it holds the password in plain text in the client's configuration, so a read-only MySQL user is the right pairing, not an optional hardening step.
An MCP server that gives a model read access to a MySQL database. There is one tool, `query`, and it runs inside a read-only transaction; the schema is exposed separately as resources, so a model can learn the table structure without spending a query on it.
- `query` takes a `sql` string and executes it inside a READ ONLY transaction
- A schema resource per table at `mysql://<host>/<table>/schema`, carrying column names and data types as JSON
- Schemas are discovered from the database metadata rather than configured by hand
- Authentication travels in the connection URL, in the form `mysql://username:password@host:port/database`
- Both the query tool and the schema resources authenticate with the same credentials
Node.js, and a reachable MySQL server. Clone the repository, run `npm run prepare` and `npm install`, then `npm link` to put `mysql-mcp-server` on the path. The client launches that command with the connection URL as its only argument. The README recommends giving the connecting MySQL user read-only permissions and keeping the credentials out of a committed config file — the connection string carries the password.
One command plus a key — mysql-mcp-server mysql://user:password@localhost:3306/mydb, then supply credentials