MCP Server for MySQL: The Options Compared

An MCP server for MySQL is a small process that exposes your database to an AI client — Claude, Cursor, Windsurf — as a set of callable tools: list tables, read a schema, run a query. There are several real options, and they mostly differ on three axes: how many database engines they speak, whether they default to read-only, and how much they trim result payloads so you don't burn the model's context on a wide SELECT *.

This piece names the five servers worth knowing, tells you which to skip, and gives you a minimal config that actually runs. All of these run locally over stdio, which is normal — roughly 90% of MCP servers do — so the server sees the same MySQL your machine can reach, no hosted middleman.

The five options, at a glance

If you want the short version: use DBHub unless you have a reason not to. It's zero-dependency, token-efficient, and speaks MySQL, Postgres, SQL Server, MariaDB and SQLite from one binary, so you don't end up running a different server per engine.

Here's the field:

Server	Engines	Read-only default	Best for
DBHub	MySQL, Postgres, SQL Server, MariaDB, SQLite	Yes (configurable)	Most people; one server for many DBs
MCP Server for MySQL	MySQL only	Yes (write optional)	MySQL-only shops that want a focused tool
MySQL MCP Server	MySQL only	Yes	Safe schema inspection + sampling
MCP Alchemy	Any SQLAlchemy DB (MySQL, Postgres, Oracle, MSSQL, SQLite)	Read-focused	Polyglot stacks already on Python
CentralMind Gateway	Many, via generated gateway	Configurable	Serving a DB to many consumers, not one client

Two of these overlap heavily in name — MCP Server for MySQL and MySQL MCP Server — so read the slug, not the label, when you install.

DBHub: the default pick

Start with DBHub. It's the one I'd reach for first, and the reason is boring in the right way: it has no runtime dependency stack to fight, it defaults to read-only, and it's built to be token-efficient — it trims and shapes results so a query against a wide table doesn't dump ten thousand tokens into the model's window.

That last point matters more than it sounds. Every column a server hands back competes for the same context budget as your actual conversation. A server that returns raw rows verbatim will quietly wreck a long agent session.

Because DBHub also speaks Postgres, MariaDB, SQL Server and SQLite, one entry in your config covers most of a real stack. If your project touches only MySQL and you want a tool with a smaller surface, the two MySQL-only servers below are reasonable — but you're trading breadth for very little.

The MySQL-only servers

Use a MySQL-only server when you want the smallest possible tool surface and you'll never point it at another engine. Two fit that bill.

MCP Server for MySQL gives read-only access by default and lets you opt into writes explicitly. That default is the correct posture: an AI client with unsupervised DELETE rights is a bad afternoon waiting to happen. Keep it read-only unless a specific task needs otherwise, and even then scope the credentials.

MySQL MCP Server leans into safe inspection — query, sample rows, and inspect schemas — which is exactly the loop you want when the model is exploring an unfamiliar database. Both are fine; DBHub simply does the same job and four other engines besides.

MCP Alchemy and CentralMind: the specialists

Reach for these two only when your situation is theirs.

MCP Alchemy connects Claude to anything with a SQLAlchemy driver — MySQL, Postgres, Oracle, MS SQL, SQLite. Pick it if you're already a Python shop and your database mix is genuinely polyglot; you inherit SQLAlchemy's broad driver support and its config conventions. If you're only on MySQL, it's more machinery than you need.

CentralMind Gateway is a different animal: it auto-generates a secure, LLM-optimized MCP server or REST API in front of your database. That's aimed at serving one database to many consumers with access controls, not at wiring a single laptop to a single DB. If you're an individual developer connecting your own client, it's overkill — but it's the right call when the database is shared infrastructure.

The minimal config that works

Add one server, not five. Here's a minimal DBHub entry for a client that reads a JSON config (Claude Desktop, Cursor, and most others share this mcpServers shape):

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["-y", "@bytebase/dbhub", "--dsn", "mysql://user:pass@localhost:3306/mydb"]
    }
  }
}

Use a read-only database user for that DSN — that's your real safety boundary, not a flag. If a task needs writes, give it a second, tightly-scoped credential rather than granting the read tool write rights. For the full walk-through of where this file lives per client and how to reload it, see how to add an MCP server, and use the config generator if you'd rather not hand-write it.

One rule that saves you later: don't stack all five of these at once. Most clients get vague and slow past roughly 40 exposed tools, and five overlapping database servers is a fast way to blow that budget. One server, one read-only credential, done.

How to choose in one line

Default to DBHub for its breadth and token discipline; drop to a MySQL-only server for a smaller surface; use MCP Alchemy for polyglot Python stacks and CentralMind when the database is shared infrastructure. If you're still comparing, the best MCP servers list flags which are official versus community-maintained — worth checking, since a database tool is one place you want an active maintainer. You can also browse related capabilities or alternatives if none of these fit your engine.