DatabasesMCP servermeasured 19 Aug 2026

MySQL

MySQL MCP Server is a community-built stdio bridge from benborla29 that hands an AI agent a single tool, mysql_query, for running SQL against a MySQL database you point it at. It is not an Oracle product and not an official reference server. One tool, one required parameter, no resources or prompts advertised.

community (benborla29) · protocol 2025-06-18 · v1.0.0 · measured by Keyoor

BootBOOTS ✓We started it and initialize came back in 17.0s.

Tools1tools/list payload 400 bytes

Context tax~100estimated tokens for the whole tools/list, chars/4 estimate

Resources / prompts— / —counts returned by resources/list and prompts/list

Measured19 Aug 2026one run of the harness, clean environment, no credentials · how we test

How we started it

npx -y @benborla29/mcp-server-mysql

Verdict

Use it if you want the thinnest possible SQL surface in front of a model and you already trust whatever is issuing the queries. When we booted it the tools/list came back at ~100 tokens (chars/4 estimate, measured 2026-08-19), which is about as cheap as a database connector gets. The reason against is the startup: initialize took 16,976 ms in our clean-env run and the process still exited with code 1 on our overall timeout, so it is slow to come up and it did not stay up unattended.

Use it if

You want a read-and-write SQL escape hatch for an agent and would rather write the guardrails yourself than inherit somebody's twelve-tool schema browser.

Your context budget is already spent on other servers and you need the database connector to cost almost nothing to list.

You are pointing the agent at a scratch or replica MySQL instance where a bad generated query is an annoyance, not an incident.

You prefer a single named tool in your transcript, because it makes auditing what the model actually ran a grep instead of a project.

Skip it if

You need the agent to discover schema on its own: with one query tool and nothing in resources or prompts, the model learns your tables by guessing and failing.

You are wiring this into anything that boots on demand, because a cold npx start of the length we measured will time out inside most clients.

You want the server to enforce read-only or row limits for you; the safety story here is your database user's grants, and nothing else.

You need a supported product with a vendor behind it rather than a community package at version 1.0.0.

Your MySQL is behind a bastion or requires TLS client certs and you are not prepared to prove that npx-launched process can reach it.

The bill for your context window

Tool	Est. tokens	Described?	Required params
mysql_query	~100	yes (102 chars)	1

You will not find much lighter than this. The whole tools/list payload is 400 bytes, estimated at 100 tokens by the chars/4 method, and all of it is the one mysql_query tool with a 102-character description and a single required parameter. Compare that with Notion, the heaviest server we measured in this batch, whose tool list runs into five figures of estimated tokens. The tax here is negligible; what you pay instead is comprehension. A model that gets one terse tool and no schema resources spends its tokens on failed queries and retries rather than on the tool list, and those retries do not show up in any context-tax number.

Setup reality

It runs as npx -y @benborla29/mcp-server-mysql over stdio, and it needs connection details in the environment before it is any use. Our clean-env probe passed no credentials at all, so the harness recorded no env hints from stderr; consult the README for the exact host, port, user, password and database variable names it expects. The only stderr we captured was an npm deprecation warning about node-domexception, which is noise from a transitive dependency, not the server. Budget for the npx cold start on first run, and pin the package if you care about reproducible launches. Give it a database user scoped to exactly the tables you are willing to have rewritten, because the server will not do that for you.

Questions people ask

Did the MySQL MCP server actually start?

Yes. It completed initialize and answered tools/list on protocol 2025-06-18, reporting itself as MySQL MCP Server version 1.0.0. But initialize took 16,976 ms and the process ended on our overall timeout with exit code 1, so treat the boot as successful and the lifetime as unproven.

How many tools does it expose?

One: mysql_query, with one required parameter and a 102-character description. There were no resources or prompts reported. Everything the agent can do here it does by writing SQL, which is either the appeal or the problem depending on who is watching the transcript.

Is it safe to point at a production database?

Not without work. The server offers no read-only mode we could observe, so your only real control is the grants on the MySQL user you give it. Create a dedicated account, restrict it to the schemas you accept losing, and log the queries on the database side.

What is behind the long cold start?

Our run resolved and installed the package through npx with no warm cache, which dominates that 16,976 ms figure. A pinned local install should come up far faster, though we did not measure that variant, so take the improvement as expected rather than proven.

Other databases servers we started

Server	Vendor	Boots	Context tax
Chroma	Chroma	✗	~0 tokens
Elasticsearch	Elastic	✗	~0 tokens
MongoDB	MongoDB	✓	~9,462 tokens
Pinecone	Pinecone	✓	~6,165 tokens
PostgreSQL (archived)	Anthropic (archived)	✓	~33 tokens
Qdrant	Qdrant	✗	~0 tokens
Supabase	Supabase	✗	~0 tokens

How this page is made: the server is spawned as an unprivileged user with a clean environment and no credentials, then asked for its tools, resources and prompts over stdio. Token figures are estimates at four characters per token, not a tokenizer count. One run, one machine. Corrections: contact the desk.

← All measured MCP servers