mcp-server-mysql: read-only MySQL access for Claude and other MCP clients
A Model Context Protocol server that provides read-only access to MySQL databases. This server enables LLMs to inspect database schemas and execute read-only queries.
At a glance
- What is it?
- benborla/mcp-server-mysql is an MIT-licensed Model Context Protocol server that exposes one SQL tool and a schema resource to an LLM. Its safety story rests on write flags being off by default, and its documentation leaves the permission model less specified than the feature list suggests.
- Who is it for?
- Adopt it if you want an LLM to read MySQL schemas and run SELECTs through Claude Code or Claude Desktop, and you can live with the write path being gated by environment flags alone. Do not adopt it if you need row-level or column-level access control enforced by the server, or if your threat model assumes the model itself is untrusted.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 50 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills: an LLM that can see your schema
Most people asking an LLM about a database end up pasting a CREATE TABLE dump into a chat window. The dump goes stale, the model invents columns, and the answer is only as good as the paste. mcp-server-mysql replaces that paste with a live connection. It is a Model Context Protocol server, so an MCP-capable client such as Claude Code or Claude Desktop can call into a running MySQL instance instead of guessing.
The audience is narrow and identifiable. You are a developer or data-adjacent engineer already using an MCP client, you have a MySQL 5.7 or 8.0 instance reachable from your machine, and you want the assistant to answer questions like which tables reference a given column. The README states the requirement plainly: Node.js v20+ and a MySQL user with appropriate privileges. If you are not already running an MCP client, this project has nothing to offer you yet, because the server is a backend, not an application.
One tool and one resource: the whole surface area
The README lists two MCP primitives. The tool is mysql_query, described as executing SQL queries, read-only by default, with write operations enabled per flag. The resource is mysql://tables, which lists all tables and column metadata for the connected database. That is the entire documented interface.
This matters more than it looks. A small surface area means the model has fewer ways to go wrong. It also means the server is not a database abstraction layer. There is no query builder, no schema-diff tool, no migration helper. The model writes SQL and the server runs it. Everything the assistant knows about your schema arrives through that one resource, so if the resource truncates or omits something, the model will not know it exists.
The README does not describe how the resource handles large schemas, whether it paginates, or what happens when a database has hundreds of tables. That is a gap worth testing on your own instance before you rely on it.
Read-only by default is a flag, not a sandbox
The safety design is stated in one line: all write operations are disabled by default, and enabled with ALLOW_INSERT_OPERATION=true, ALLOW_UPDATE_OPERATION=true, ALLOW_DELETE_OPERATION=true. The feature list also mentions schema-specific permissions, described as per-database read/write control, and PII redaction, described as automatic masking of sensitive data in results.
Read that combination carefully. The default posture is safe, but the enforcement mechanism is a set of environment variables read at startup. Anyone who can edit the client configuration file can flip a flag. The README does not claim the server validates SQL beyond those flags, and it does not describe a parser that inspects statement types. If you enable updates for one database, the documentation does not say what stops a query from touching another database the connection can reach. Schema-specific permissions are listed as a feature, but the README defers the details to docs/CONFIGURATION.md, which is not reproduced here.
That is the honest trade-off. The default is conservative, the configuration is simple, and the boundary is only as strong as the MySQL grants behind it. Create a dedicated MySQL user with SELECT-only privileges and the flag discussion becomes a second line of defence rather than the first.
Getting it running in Claude Code or Claude Desktop
The README gives two install paths. For Claude Code it is a single command that registers the server with the client:
claude mcp add mcp_server_mysql -e MYSQL_HOST="127.0.0.1" -e MYSQL_PORT="3306" -e MYSQL_USER="root" -e MYSQL_PASS="your_password" -e MYSQL_DB="your_database" -- npx @benborla29/mcp-server-mysql
For Claude Desktop and other clients, the same configuration goes into the client's JSON config under mcpServers, with command set to npx, args set to ["-y", "@benborla29/mcp-server-mysql"], and the five environment variables under env.
Note the package name. The install command uses @benborla29/mcp-server-mysql, which differs from the repository path benborla/mcp-server-mysql. Getting that wrong produces an npx failure that looks like a network problem.
The README also points to docs/INSTALLATION.md for Smithery, Cursor, Codex, local repo and remote mode, and to docs/CONFIGURATION.md for the full environment variable list. Remote mode is described as HTTP transport with bearer token auth, and SSL/TLS support is listed with an mTLS option, but the README does not show the variable names for either. If you need those, the linked docs are the only source. For contributing, the repository uses pnpm: clone, pnpm install, pnpm run build, pnpm test.
Where the design gets thin: multi-DB, tunnels and redaction
Three features appear in the list without mechanism in the README. Multi-DB mode is described as querying across multiple databases without reconnecting, with a separate README-MULTI-DB.md. SSH tunnel support is described as built-in support for remote databases. PII redaction is described as automatic masking of sensitive data in results, with docs/PII-REDACTION.md.
Each of these is the kind of feature where the details decide whether it is usable. For PII redaction, the question is what triggers a mask: column names, data patterns, or an explicit list. A redactor that guesses from column names will miss a column called notes and will over-mask a column called phone_number that holds internal extension codes. The README does not say which approach is used.
For SSH tunnels, the question is whether the server opens the tunnel itself or expects one to already exist. Built-in support suggests the former, but no configuration keys are shown. For multi-DB mode, the question is whether permissions are evaluated per database or per connection. The feature list says schema-specific permissions exist, so the two features interact, and the README does not explain how.
None of this is a reason to avoid the project. It is a reason to treat the README as an index and the docs directory as the actual specification.
The alternative that takes the opposite approach
The obvious comparison is a general-purpose database MCP server that supports several engines, or a direct MySQL client wrapped in a shell tool the assistant can call. Both differ from this project in the same way: they push the safety decision outward.
With a shell-wrapped mysql client, the model composes a command line and the operating system user's credentials decide what happens. There is no allow-list of statement types, no per-database flag, and no redaction layer. The upside is that anything the client can do, the assistant can do, including EXPLAIN plans and administrative commands. The downside is that a hallucinated DROP TABLE is exactly as executable as a SELECT.
mcp-server-mysql inverts that. The tool is fixed, the default is read-only, and the configuration lives in the client's env block rather than in the model's output. You give up flexibility for a narrower failure surface. If your workflow needs the assistant to run mysqldump or inspect replication status, this server will not help, because the documented tool is mysql_query and nothing else. If your workflow is questions about schema and data, the narrower surface is the point.
A second alternative is to skip MCP entirely and give the assistant a read replica with a SELECT-only account. That solves the same problem without a server process, but it loses the schema resource, so the model has to discover structure through queries.
Upgrades, licence and what maintenance actually costs
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the most permissive common option and it imposes no copyleft obligation on your own code. It also means the authors offer no warranty, so the operational risk sits with you. Nothing here is legal advice; read the LICENSE file if the distinction matters to your organisation.
Release cadence, based on the supplied release list, shows v2.0.7 in November 2025, v2.0.8 in January 2026 and v2.0.9 in June 2026, with the last push to the repository in July 2026. That is a slow but non-zero cadence: roughly one release every few months. For a server whose job is to shell out to a MySQL driver, that is reasonable, because the underlying protocol does not move quickly. It does mean a fix for a newly discovered behaviour may wait a release cycle.
The upgrade cost is low by construction. There is no database schema to migrate, no daemon to restart on a schedule, and no state stored between sessions. You bump the package version in the client config or re-run the claude mcp add command. The real maintenance burden is elsewhere: rotating the MySQL credentials in that env block, and re-reading docs/CONFIGURATION.md after a major version, since the whole configuration surface is environment variables and a renamed flag fails silently as a disabled feature rather than as an error.
Editorial conclusion
Adopt it if you want an LLM to read MySQL schemas and run SELECTs through Claude Code or Claude Desktop, and you can live with the write path being gated by environment flags alone. Do not adopt it if you need row-level or column-level access control enforced by the server, or if your threat model assumes the model itself is untrusted. Before rollout, verify which MySQL user the server connects as, confirm the effect of ALLOW_UPDATE_OPERATION and ALLOW_DELETE_OPERATION in your own deployment, and read docs/CONFIGURATION.md for the full env var list rather than trusting the README summary.
Community notes