Which integrations are available for this server?

Enables running SQL queries (SELECT, INSERT, UPDATE, DELETE) against a MySQL database, with support for read-only or read-write mode, parameterized queries, and automatic reconnect.

How do I use mysql-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mysql-mcp-server Show me the first 10 records from the customers table" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

mysql-mcp-server

by bomsan69

Overview Schema Related Servers Score Discussions

Python

Local

mysql-mcp-server

A Model Context Protocol (MCP) server that lets an MCP client (Claude Desktop, Claude Code, etc.) run SQL against a MySQL database through four tools: select, insert, update, and delete.

The server runs as a uv-managed Python package and communicates with the client over stdio, as a subprocess started by the client.

Requirements

Python 3.11+
uv
A reachable MySQL server

Related MCP server: Universal Database MCP Server

Installation

uv sync

Configuration

The server requires six values, each settable via environment variable and/or CLI flag (CLI flags take priority over environment variables):

Parameter	Env var	CLI flag	Required	Default
Mode	`MYSQL_MODE`	`--mysql-mode`	yes	— (`readonly` or `readwrite`)
Host	`MYSQL_HOST`	`--mysql-host`	yes	—
Port	`MYSQL_PORT`	`--mysql-port`	no	`3306`
User	`MYSQL_USER`	`--mysql-user`	yes	—
Password	`MYSQL_PASSWORD`	`--mysql-password`	yes	—
Database	`MYSQL_DATABASE`	`--mysql-database`	yes	—

If a required value is missing, or MYSQL_MODE is not readonly/readwrite, the server prints an error to stderr and exits with status code 1 without starting.

readonly mode: only the select tool is allowed. insert/update/delete are rejected with a PERMISSION_DENIED error.
readwrite mode: all four tools are allowed.

The mode is fixed for the lifetime of the process; it cannot be changed at runtime.

Security recommendation: readonly mode is an application-level guard, not a substitute for database privileges. Where possible, point readonly mode at a MySQL account that only has SELECT grants.

Is a .env file required? No. The server itself never reads .env files — it only reads CLI flags and real process environment variables (os.environ). How you get values into that environment depends on how you run it:
As an MCP server (see Connecting from an MCP client below): the client (Claude Desktop/Code) spawns the server process and injects the env block from its own JSON config directly as environment variables. No .env file is involved or needed.
Running the CLI directly for local dev/testing: .env is just a convenience so you don't have to export six variables by hand. Copy .env.example to .env, fill in real values, and load it explicitly — it is not read automatically:
uv run --env-file .env mysql-mcp-server
.env is git-ignored and must never be committed.

Running

# Environment variables (or use `uv run --env-file .env mysql-mcp-server`, see above)
export MYSQL_MODE=readonly
export MYSQL_HOST=127.0.0.1
export MYSQL_PORT=3306
export MYSQL_USER=app_user
export MYSQL_PASSWORD=secret
export MYSQL_DATABASE=mydb
uv run mysql-mcp-server

# Or, equivalently, via CLI flags
uv run mysql-mcp-server \
  --mysql-mode readonly \
  --mysql-host 127.0.0.1 \
  --mysql-port 3306 \
  --mysql-user app_user \
  --mysql-password secret \
  --mysql-database mydb

Connecting from an MCP client

Claude Desktop / Claude Code

Add an entry to your MCP client's server config (e.g. Claude Desktop's claude_desktop_config.json, or .mcp.json for Claude Code):

{
  "mcpServers": {
    "mysql": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/mysql-mcp-server",
        "run",
        "mysql-mcp-server"
      ],
      "env": {
        "MYSQL_MODE": "readonly",
        "MYSQL_HOST": "127.0.0.1",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "app_user",
        "MYSQL_PASSWORD": "secret",
        "MYSQL_DATABASE": "mydb"
      }
    }
  }
}

Restart the client after editing the config. The select, insert, update, and delete tools (subject to MYSQL_MODE) should then be available to the model.

Tools

All four tools take {"query": string, "params"?: array} and always use %s parameter-binding placeholders in query — never string-format user input into a query.

Tool	Allowed in	Query must start with	Success `data` shape
`select`	any mode	`SELECT` / `WITH`	`{rows, row_count, truncated}` (capped at 1000 rows)
`insert`	`readwrite` only	`INSERT`	`{affected_rows, last_insert_id}`
`update`	`readwrite` only	`UPDATE`	`{affected_rows}` (+ `warning` if no `WHERE`)
`delete`	`readwrite` only	`DELETE`	`{affected_rows}` (+ `warning` if no `WHERE`)

Every tool call returns one of:

{ "success": true, "data": { ... } }

{ "success": false, "error": { "code": "...", "message": "..." } }

Error codes: PERMISSION_DENIED, INVALID_QUERY_TYPE, MULTI_STATEMENT_NOT_ALLOWED, DB_CONNECTION_ERROR, DB_EXECUTION_ERROR, INTERNAL_ERROR.

Multi-statement queries (;-separated) and any DDL/privilege statement (DROP, TRUNCATE, ALTER, GRANT, CREATE USER, ...) are always rejected, since only the four whitelisted statement types above are ever accepted.

Development

uv sync
uv run ruff format .
uv run ruff check .
uv run pytest -v
uv run uv build   # packaging check

Troubleshooting

Server exits immediately with status 1: a required MYSQL_* value is missing or MYSQL_MODE is invalid — check stderr for which one.
DB_CONNECTION_ERROR: MySQL is unreachable, or the credentials are wrong. The server keeps running and will retry the connection on the next tool call.
PERMISSION_DENIED on insert/update/delete: the server is running in readonly mode; restart it with MYSQL_MODE=readwrite if writes are intended.

Version history

0.1.0 — Initial release: select/insert/update/delete tools, readonly/ readwrite mode policy, stdio MCP transport, automatic reconnect-and-retry on lost connections.

Available Tools

4 tools

deleteA

Execute a DELETE statement and return the affected row count. Only available when the server is running in 'readwrite' mode; rejected with PERMISSION_DENIED in 'readonly' mode. A DELETE with no WHERE clause is executed but flagged with a warning, since it removes every row in the table. Always use %s placeholders in query with values passed via params; never concatenate user-supplied values into query.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses the readwrite/readonly mode behavior, the warning flag for DELETE without WHERE, and the security requirement to use placeholders. These are significant behavioral traits beyond what the schema shows.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each earning its place: core function, mode restriction, warning, and security guideline. No fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a deletion tool with output schema present, the description covers the essential aspects: return value (row count), mode availability, dangerous no-WHERE behavior, and parameter usage. It is sufficiently complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain both parameters. It does so by clarifying that `query` is a DELETE statement with %s placeholders and `params` provides values, plus warns against concatenation. This adds substantial meaning beyond the basic schema type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it executes a DELETE statement and returns the affected row count. This distinguishes it from sibling tools select, insert, and update by specifying the exact SQL operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the tool is only available in 'readwrite' mode and rejected with PERMISSION_DENIED in 'readonly' mode, providing clear context for when it can be used. Does not explicitly compare to alternatives, but the purpose and mode restrictions give sufficient guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

insertA

Execute an INSERT statement and return the affected row count and last insert id. Only available when the server is running in 'readwrite' mode; rejected with PERMISSION_DENIED in 'readonly' mode. Always use %s placeholders in query with values passed via params; never concatenate user-supplied values into query.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

While no annotations are provided, the description discloses key behavioral traits: the mode-dependent availability (PERMISSION_DENIED in readonly mode) and the return values (affected row count and last insert id). It also provides security guidance on parameterization, which is essential for agent behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose, followed by mode restriction and security guidance. Every sentence earns its place; no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, which may explain return values, so the agent knows what to expect. The description covers the key semantics: the operation and parameterization. It gives clear guidance on mode requirements and security, which is sufficient for a tool with only two simple parameters and an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It does explain the purpose of `query` (the INSERT statement) and `params` (values for placeholders), but it doesn't detail the exact types or format expectations beyond mentioning placeholders. The baseline is 3 because the description adds some meaning but not fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to execute an INSERT statement and return the affected row count and last insert id. It distinguishes itself from siblings (select, update, delete) by naming the specific SQL operation, though it could explicitly contrast with siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: only available in 'readwrite' mode, and it warns against concatenating user-supplied values, instructing to use placeholders. It does not explicitly mention when not to use it (e.g., for other SQL operations), but the sibling names make that clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

selectA

Execute a read-only SELECT (or WITH ... SELECT) statement and return matching rows. Always available regardless of MYSQL_MODE. Always use %s placeholders in query with values passed via params; never concatenate user-supplied values into query.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the read-only safety profile, availability, and the critical placeholder requirement. It does not mention error behavior, transaction details, or return format, but the output schema covers return values. It adds meaningful context beyond what annotations would provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences, each adding value: purpose, availability, and security guideline. It is front-loaded with the core purpose and contains no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool (2 parameters, no nested objects, output schema present), the description covers purpose, read-only nature, availability, and placeholder usage. It is complete for a SELECT tool and the output schema handles return value documentation. No significant gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains that `query` is a SQL statement with %s placeholders and that `params` holds the substitution values, clarifying the relationship between the two parameters. It does not enumerate all parameter types, but the schema is simple and the guidance is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Execute a read-only SELECT (or WITH ... SELECT) statement and return matching rows,' which is a specific verb+resource+scope. It clearly distinguishes from the sibling tools insert, update, and delete by emphasizing the read-only nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: always available regardless of MYSQL_MODE, and the requirement to use %s placeholders with params rather than concatenating values. It implies this is for read queries while siblings are for writes, but does not explicitly name alternatives or exclusion scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

updateA

Execute an UPDATE statement and return the affected row count. Only available when the server is running in 'readwrite' mode; rejected with PERMISSION_DENIED in 'readonly' mode. An UPDATE with no WHERE clause is executed but flagged with a warning, since it affects every row in the table. Always use %s placeholders in query with values passed via params; never concatenate user-supplied values into query.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description reveals several behavioral traits: returns affected row count, is rejected in readonly mode, warns when no WHERE clause (affects all rows), and enforces parameterized queries. These go beyond the schema and give a clear picture of the tool's behavior and side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact yet information-dense, with each sentence serving a specific purpose: purpose, mode condition, warning, and security guideline. It is well-structured and front-loaded, with no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the operation, mode constraints, warning behavior, and security practice, the description covers all essential aspects for using the tool correctly. It specifies the return value (affected row count) and does not leave critical gaps; it is complete for the context of an UPDATE tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description clarifies the meaning and relationship of the parameters: query is an UPDATE SQL statement, params are values for placeholders, and %s placeholders must be used. This adds significant semantic detail beyond the bare schema, which only lists query and params as types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes an UPDATE statement and returns the affected row count, which is distinct from the sibling tools (select, insert, delete). The verb 'execute' and resource 'UPDATE statement' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit conditions for usage—only in readwrite mode, with a warning for missing WHERE clause—and gives security guidance (use %s placeholders, never concatenate user-supplied values). However, it does not explicitly contrast with when to use insert or delete, so it stops short of complete alternative differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Aug 21, 2026
- First observeddelete
- First observedinsert
- First observedselect
- First observedupdate

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool maps to a distinct SQL operation (SELECT, INSERT, UPDATE, DELETE) with no functional overlap. Misselection is impossible because the actions are mutually exclusive.

Naming Consistency5/5

All tool names are single lowercase verbs that directly match their SQL counterparts, forming a perfectly consistent and predictable pattern.

Tool Count5/5

Four tools precisely cover the core CRUD operations for a database server without redundancy or excessive granularity, matching the expected scope.

Completeness5/5

The tool surface provides full coverage of data manipulation (create, read, update, delete) with no obvious gaps. Additional schema or transaction management is outside the stated read/write mode scope.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
mcpOAuth
io.prisma
MCP server for managing Prisma Postgres.
Databases Developer Tools
247
SRI — MCP Server Inspector A
biz.sri-test
2,000+ MCP servers read at source level. Know what one does before you connect. Free, no key.
Developer Tools
21

Related MCP Servers

MySQL Database Access
Databases RAG Systems
dpflucas
A
license
A
quality
D
maintenance
An MCP server that provides read-only access to MySQL databases.
Updated a year ago (2025-04-22 10:22 UTC)
4
454
72
MIT
Universal Database MCP Server
xiaoshi7915
F
license
Not graded
quality
D
maintenance
A versatile MCP server that connects to multiple relational databases (MySQL, PostgreSQL, Oracle, SQL Server, SQLite) and enables secure read-only SQL query execution and metadata access.
Updated a year ago (2025-04-28 22:50 UTC)
4
-
mysql-mcp
Databases Developer Tools
eastgatedev
A
license
Not graded
quality
B
maintenance
A MySQL MCP server for local stdio clients, enabling database queries and management with read-only/write modes, audit logging, and configurable security.
Updated 3 months ago (2026-06-18 14:40 UTC)
1,081
MIT
MySQL Ops MCP
Databases Developer Tools
lemonq3q
F
license
Not graded
quality
C
maintenance
A generic MCP server for MySQL operations, enabling listing databases/tables, describing schemas, running read-only SQL, and optionally executing write SQL with logging.
Updated 2 months ago (2026-07-06 00:46 UTC)
1
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bomsan69/mysql-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server