mysql_mcp_server: A Read-First MySQL Bridge for MCP Clients

The gap this fills between an MCP host and a live MySQL instance

An MCP host such as Claude Code or Claude Desktop speaks the Model Context Protocol, not the MySQL wire protocol. Without a bridge, an assistant asked to explain a table has no way to look at it. mysql_mcp_server is that bridge: a Python process that connects to MySQL with a standard connector and presents the database as MCP resources, tools and prompts. The README frames the goal as making "database exploration and analysis safer and more structured through a controlled interface", and the controls are visible in the tool surface rather than hidden in a policy layer. The intended user is an engineer or analyst who already runs an MCP-capable client and wants read-oriented access to a MySQL schema without granting the client a raw connection string. It is not a query console for arbitrary SQL work, and it is not a proxy that rewrites or audits queries.

Three tools, one transport-agnostic process

The MCP surface is small. execute_sql takes a single query string and covers SELECT, SHOW, DESCRIBE and DML, with the README noting that DML operations carry a destructive hint. get_schema_info returns column names, types, nullability, default values and comments, and accepts an optional table_name. get_table_sample returns a representative slice of rows, with a limit argument capped at 20. Table names are validated against an allowlist of alphanumeric characters, underscores and $, with a dot permitted as the database-table separator. That validator is the main injection guard on the identifier path, and it is why a name containing a quote or a space is rejected before any SQL is composed. Multi-database mode is the default when MYSQL_DATABASE is unset: list_resources returns all user databases with system databases filtered out, and queries must use fully qualified names such as mydb.mytable. The README is explicit that only single SQL statements are supported, so USE db; SELECT ... fails. Transport is a runtime choice. MCP_TRANSPORT=stdio keeps everything on the parent process pipes; MCP_TRANSPORT=sse starts an HTTP listener, with MCP_SSE_HOST, PORT (a fallback for MCP_SSE_PORT) and MCP_SSE_ALLOWED_HOSTS controlling binding and Host header checks. The README recommends SSE for remote or self-hosted deployments, which is a reasonable default given that stdio requires the host to spawn the process locally.

Getting it running: pip, uvx, or a host CLI

The shortest path is pip install mysql-mcp-server, after which the module can be launched by an MCP host. The README also gives a Claude Code CLI registration: claude mcp add --transport stdio designcomputer-mysql_mcp_server uvx mysql_mcp_server. For Smithery, the documented command is npx -y @smithery/cli install designcomputer/mysql_mcp_server --client claude. An Autohand Code CLI example passes credentials inline: autohand mcp add mysql env MYSQL_HOST=localhost MYSQL_PORT=3306 MYSQL_USER=your_username MYSQL_PASSWORD=your_password MYSQL_DATABASE=your_database uvx mysql_mcp_server, with --scope project available to keep the registration in the current workspace. Configuration is entirely environment driven. MYSQL_HOST, MYSQL_PORT (default 3306), MYSQL_USER, MYSQL_PASSWORD and the optional MYSQL_DATABASE are the core keys. Beyond those, the README lists MYSQL_SSL_MODE with values DISABLED, REQUIRED, VERIFY_CA and VERIFY_IDENTITY, MYSQL_CONNECT_TIMEOUT in seconds, MYSQL_SQL_MODE defaulting to TRADITIONAL, MYSQL_CHARSET, MYSQL_COLLATION, MYSQL_AUTH_PLUGIN for older servers that still need mysql_native_password, MYSQL_USE_PURE to force the pure-Python connector, and MYSQL_RAISE_ON_WARNINGS. SSH tunneling is a separate block: MYSQL_SSH_ENABLE, MYSQL_SSH_HOST, MYSQL_SSH_PORT, MYSQL_SSH_USER, MYSQL_SSH_KEY_PATH, MYSQL_SSH_REMOTE_HOST, MYSQL_SSH_REMOTE_PORT and MYSQL_LOCAL_PORT. The server loads a .env file through python-dotenv from the process working directory and its parents, but the README carries an explicit warning that Claude Code and Claude Desktop start the server from their own directory, so the project .env is not found and the process reports Missing required database configuration. Put the MYSQL_* values in the env block of the MCP config instead.

Where the single-statement rule bites

The most consequential limitation is the one-statement restriction. It rules out the workflow many people reach for first: switch database, then query. In multi-database mode you work around it with database.table qualification on every object, which the tools accept for get_schema_info and get_table_sample as well as execute_sql. But anything that genuinely needs two statements, such as setting a session variable and then reading with it, or wrapping a change in an explicit transaction, cannot be expressed through execute_sql. The same applies to stored procedures and to any script that assumes a persistent session state across calls. A second constraint is the sample cap of 20 rows in get_table_sample, which is enough to learn column formats and not enough to profile a distribution. Third, execute_sql accepts DML. The README says destructive operations are marked with a hint, but a hint is a signal to the model, not an enforcement boundary. If the MYSQL_USER you supply has INSERT, UPDATE or DELETE rights, the client can attempt them. The practical mitigation is to grant the account SELECT and SHOW privileges only, and to leave MYSQL_RAISE_ON_WARNINGS at its default unless you have a reason to change error behaviour. Finally, the identifier allowlist means unusual but legal MySQL names, including those with spaces or non-ASCII characters, cannot be addressed by these tools at all.

How it differs from a generic MySQL client library

The obvious alternative is to skip MCP and let the assistant call a plain MySQL driver through a shell or a small script. That approach gives full multi-statement support, explicit transactions and no 20-row sampling cap, because you are writing ordinary Python. What it does not give you is a stable tool contract. The MCP host has to know which functions exist, what arguments they take and what a destructive call looks like; with mysql_mcp_server those definitions ship with the package, and the destructive hint on DML is part of the protocol metadata rather than a convention you document in a prompt. The trade is expressiveness for discoverability. A second comparison is against running a general HTTP SQL gateway and pointing the MCP host at it. That adds a network hop and a second service to secure, while mysql_mcp_server can stay on stdio with no listening socket at all. The SSE mode narrows that gap, but the README's MCP_SSE_ALLOWED_HOSTS default of localhost:{port} and 127.0.0.1:{port} shows the project expects you to think about Host header validation before exposing the port, and MCP_SSE_HOST=0.0.0.0 is documented as required for Docker or hosted setups, which is also the setting that widens exposure.

Maintenance surface and what the MIT licence leaves to you

The project is active rather than frozen: the last push is dated 2026-08-02, and v0.4.4 followed v0.4.3 by roughly an hour on 2026-07-30, with v0.4.2 about six weeks earlier. That cadence suggests small, frequent releases, which is typical for a connector that tracks client and driver changes. The upgrade cost is mostly configuration drift. New MYSQL_* keys appear as compatibility needs arise, and the README already carries several: MYSQL_AUTH_PLUGIN for older MySQL versions, MYSQL_CHARSET and MYSQL_COLLATION, MYSQL_USE_PURE to force the pure-Python connector. If you pin the package in a host config, you control when those arrive; if you run it through uvx without a version pin, you take each release on the next start. The licence is MIT, which is permissive and imposes no copyleft obligation on your own code. That is a statement about the licence text, not legal advice; if you redistribute the server inside a product, read the licence file in the repository yourself. The README also links an AgentAudit badge, which is a third-party safety label for the package rather than a property of the code you run, so treat it as a pointer to someone else's review, not as a substitute for checking your own grant statements.

Editorial conclusion

Adopt mysql_mcp_server if you want an MCP host to read MySQL schema and sample rows without writing a bespoke connector, and if you accept a single-statement, identifier-allowlisted interface. Do not adopt it if you need multi-statement scripts, transactional control, or a server that manages its own credential store; connection settings come from MYSQL_* environment variables, and the README warns that Claude Code and Claude Desktop launch the server from their own working directory, so a project .env will not be found. Verify first that your host passes MYSQL_HOST, MYSQL_PORT, MYSQL_USER, MYSQL_PASSWORD and MYSQL_DATABASE in the MCP env block, that your account has only the privileges you intend to expose, and that MYSQL_SSL_MODE is set to VERIFY_CA or VERIFY_IDENTITY rather than the documented default of DISABLED if the connection crosses an untrusted network.

Official sources

1. designcomputer/mysql_mcp_server on GitHub
2. License: MIT
3. Project website
4. README
5. Releases