Tag Archives: mcp

MySQL MCP Server v1.8.0: 37 vulnerabilities fixed, integration tests passing on MySQL 8.0, 8.4, 9.7, 26.7 and MariaDB 11.4, 12.3

MySQL MCP Server v1.8.0 is out

On paper it’s a boring release. No new tools, no new flags, nothing to reconfigure. In practice it’s one I’m glad I didn’t skip: it closes 37 known vulnerabilities that the server could actually reach, and I found them more or less by accident.


It started as a compatibility check

I had MySQL 8.4, 9.7 and 26.7 running on my test box, plus MariaDB 12.3. So I pointed the MCP server’s test suite at all of them. Mostly to tick a box before moving on to something more fun.

The code was fine. Every version passed.


MySQL 26.7 and MariaDB 12.3 join the matrix

Every pull request now runs the full integration suite against six servers:

  • MySQL 8.0, 8.4, 9.7 and 26.7
  • MariaDB 11.4 and 12.3

26.7 is the first Innovation release under Oracle’s new calendar versioning. If you follow MyVector, you know I’ve been chasing it there too.

MySQL 9.0 is out of CI. It was a short-lived Innovation release, and 9.7 covers that line now.

MySQL 8.0 is staying. Yes, it reached end of life in April. No, I’m not dropping it. Plenty of you are still on 8.0 and haven’t moved to 8.4 yet, and I’d rather keep testing it than pretend otherwise.

One more thing turned up along the way. The Sakila tests weren’t running in CI at all: the sample database was never loaded, so they skipped quietly. They run now, on every version.


Green CI, 37 vulnerabilities

CI was not fine. The vulnerability scan and the linter had been failing quietly for a while. Both were set to informational, so nothing ever turned red.

Once the scan ran again, it found 37 vulnerabilities in code the server actually calls. Most were in the Go 1.24 standard library, the rest in the SSH and MCP SDK dependencies.

v1.8.0 fixes all of them:

  • Go 1.24 → 1.26
  • golang.org/x/crypto v0.43.0 → v0.58.0
  • MCP Go SDK v1.2.0 → v1.8.0

If you use the SSH tunnel: that library jumped 15 minor versions, so I tested it through a bastion before tagging. It still connects, and it still refuses a server whose host key doesn’t match known_hosts.

And since the release, govulncheck blocks merges and releases, so this can’t quietly happen again.


Release candidates stay out of Homebrew

This one’s a bit embarrassing. When I cut v1.7.1, all four release candidates went straight to the Homebrew tap. If you ran brew upgrade that week, you got an RC. Sorry about that.

RCs now only show up on the GitHub releases page. brew upgrade only ever gives you a final release.

v1.8.0 went out the new way. rc.1 first, smoke-tested against real 8.4, 9.7, 26.7 and MariaDB 12.3 servers, then the final tag. Homebrew users never saw the RC.


Things I learned the hard way

Two, mostly.

First, don’t write [skip ci] in a commit message. Not even when you’re describing a different commit that had it. GitHub doesn’t read for context. My PR sat there with no CI run at all while I wondered what was going on. With a required check on main now, that PR would have stayed stuck until I reworded the commit.

Second, the AI code reviewers earned their keep this time. CodeRabbit spotted a startup race in the CI health checks. Codex pointed out that scanning on Linux alone misses Windows-only code. And Copilot noticed that one of my test fixes would have broken the release workflow on the very first tag. I would have found that one at release time, which is the worst time to find anything.


Upgrading

Breaking change: building from source now needs Go 1.26 or later. Homebrew, Docker and the release binaries aren’t affected, and there’s nothing to reconfigure.

Homebrew:

brew update && brew upgrade mysql-mcp-server

Docker:

docker pull ghcr.io/askdba/mysql-mcp-server:1.8.0

Or grab a binary from the v1.8.0 release. Here’s what my Mac said after brew upgrade:

$ mysql-mcp-server --version
mysql-mcp-server 1.8.0
  Build time: 2026-10-17T09:14:37Z
  Git commit: f946f1d37654b5d8958d45a027a3e68133f01d1a

The full list is in the CHANGELOG. Questions, bugs and ideas are welcome on GitHub.

MySQL MCP Server v1.7.0 is out

April 19, 2026

It took three release candidates and more CI tweaks than I’d like to admit, but v1.7.0 is finally tagged GA. Here’s what actually changed and why it matters.


The thing I kept getting asked about: add_connection

Almost every multi-database user hits the same wall: you configure your connections at startup, and that’s it. Want to point Claude at a different instance mid-session? Restart the server. Not great.

add_connection fixes that. Enable it with MYSQL_MCP_EXTENDED=1 and MYSQL_MCP_ENABLE_ADD_CONNECTION=1, and Claude can register a new named connection on the fly — DSN validation, duplicate-name rejection, and a hard block on the root MySQL user all happen before the connection is accepted. Once it’s in, use_connection it works as usual.

It’s intentionally opt-in behind two flags. Allowing an AI client to register arbitrary database connections at runtime warrants an explicit “yes, I want this” from the operator.


Finding stuff across a big schema: search_schema and schema_diff

Two tools I personally felt the absence of every time I was debugging a large schema.

search_schema does what it sounds like — pattern-match against table and column names across all accessible databases. Before this, you’d either write the query yourself or ask Claude to guess where a column lived. Now you just ask.

schema_diff is the one I’m more excited about. Point it at two databases, and it tells you what’s structurally different. Columns that exist in staging but not prod, type mismatches, missing indexes — all surface immediately. We’ve already caught more than a few “oh, that migration never ran” moments with it.


Pagination, retries, and the unglamorous stuff

run_query now supports an offset parameter for SELECT and UNION queries, returning has_more and next_offset in the response. Big result sets no longer mean hitting row caps and wondering what you missed.

Retries got a proper implementation too. Transient errors — bad pooled connections, deadlocks, lock wait timeouts — now trigger exponential backoff instead of just failing. After a driver.ErrBadConn the pool is re-pinged, which cuts recovery time noticeably after a MySQL restart.

Neither of these is flashy, but they’re the kind of thing that makes the tool feel solid rather than fragile.


Column masking

Set MYSQL_MCP_MASK_COLUMNS=email,password,ssn and those columns are redacted in every run_query response. Nothing leaves the server. No query rewrites, no application changes. It’s a small feature that a few teams have been asking for since before v1.6.


One breaking change worth knowing about: SSH host key verification

This one could bite you on upgrade if you’re using SSH tunnels. Host key verification is now on by default. The tunnel checks ~/.ssh/known_hosts (or MYSQL_SSH_KNOWN_HOSTS, or a pinned MYSQL_SSH_HOST_KEY_FINGERPRINT) before allowing the connection.

If you were running without strict host key checking, your tunnel will fail after upgrading until you either add the host key to known_hosts or explicitly opt out with MYSQL_SSH_STRICT_HOST_KEY_CHECKING=false. The opt-out exists, but it’s a MITM risk — the default is the right behavior.


Upgrading

# Homebrew
brew update && brew upgrade mysql-mcp-server

# Docker
docker pull ghcr.io/askdba/mysql-mcp-server:latest

Full changelog: github.com/askdba/mysql-mcp-server/releases/tag/v1.7.0

Questions and issues are welcome on GitHub.

Introducing Lightweight MySQL MCP Server: Secure AI Database Access


A lightweight, secure, and extensible MCP (Model Context Protocol) server for MySQL designed to bridge the gap between relational databases and large language models (LLMs).

I’m releasing a new open-source project: mysql-mcp-server, a lightweight server that connects MySQL to AI tools via the Model Context Protocol (MCP). It’s designed to make MySQL safely accessible to language models, structured, read-only, and fully auditable.

This project started out of a practical need: as LLMs become part of everyday development workflows, there’s growing interest in using them to explore database schemas, write queries, or inspect real data. But exposing production databases directly to AI tools is a risk, especially without guardrails.

mysql-mcp-server offers a simple, secure solution. It provides a minimal but powerful MCP server that speaks directly to MySQL, while enforcing safety, observability, and structure.

What it does

mysql-mcp-server allows tools that speak MC, such as Claude Desktop, to interact with MySQL in a controlled, read-only environment. It currently supports:

  • Listing databases, tables, and columns
  • Describing table schemas
  • Running parameterized SELECT queries with row limits
  • Introspecting indexes, views, triggers (optional tools)
  • Handling multiple connections through DSNs
  • Optional vector search support if using MyVector
  • Running as either a local MCP-compatible binary or a remote REST API server

By default, it rejects any unsafe operations such as INSERT, UPDATE, or DROP. The goal is to make the server safe enough to be used locally or in shared environments without unintended side effects.

Why this matters

As more developers, analysts, and teams adopt LLMs for querying and documentation, there’s a gap between conversational interfaces and real database systems. Model Context Protocol helps bridge that gap by defining a set of safe, predictable tools that LLMs can use.

mysql-mcp-server brings that model to MySQL in a way that respects production safety while enabling exploration, inspection, and prototyping. It’s helpful in local development, devops workflows, support diagnostics, and even hybrid RAG scenarios when paired with a vector index.

Getting started

You can run it with Docker:

docker run -e MYSQL_DSN='user:pass@tcp(mysql-host:3306)/' \
  -p 7788:7788 ghcr.io/askdba/mysql-mcp-server:latest

Or install via Homebrew:

brew install askdba/tap/mysql-mcp-server
mysql-mcp-server

Once running, you can connect any MCP-compatible client (like Claude Desktop) to the server and begin issuing structured queries.

Use cases

  • Developers inspecting unfamiliar databases during onboarding
  • Data teams writing and validating SQL queries with AI assistance
  • Local RAG applications using MySQL and vector search with MyVector
  • Support and SRE teams need read-only access for troubleshooting

Roadmap and contributions

This is an early release and still evolving. Planned additions include:

  • More granular introspection tools (e.g., constraints, stored procedures)
  • Connection pooling and config profiles
  • Structured logging and tracing
  • More examples for integrating with LLM environments

If you’re working on anything related to MySQL, open-source AI tooling, or database accessibility, I’d be glad to collaborate.

Learn more

If you have feedback, ideas, or want to contribute, the project is open and active. Pull requests, bug reports, and discussions are all welcome.