Skip to main content
Glama
liliangshan

MCP MySQL Server

by liliangshan
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

MCP MySQL Server

A MCP MySQL server with DDL support, permission control and operation logs.

Version History

v3.1.0 (Latest)

  • ✅ BIGINT Precision Support: Added supportBigNumbers and bigNumberStrings options to prevent precision loss for large integers (e.g., order_id, user_id > 2^53 - 1). Values are returned as strings to maintain full precision.

v3.0.0

  • ✅ Readonly Mode: Added READONLY environment variable - when enabled, only SELECT and SHOW commands are allowed (highest priority check)

  • ✅ Tool Prefix Support: Added TOOL_PREFIX environment variable for tool name isolation and config separation

  • ✅ Project Branding: Added PROJECT_NAME environment variable for custom tool descriptions

  • ✅ Enhanced Permission Check: Improved check_permissions tool with detailed messages and readonly mode warnings

  • ✅ Default Log Path: Changed default log directory from ./logs to ./.setting (or ./.setting.<TOOL_PREFIX> if prefix is set)

  • ✅ Multiple Instance Support: Full support for running multiple MySQL server instances with isolated configurations

  • ✅ Improved CLI: Updated CLI to support all new environment variables and log path configuration

v2.0.1

  • ✅ DDL SQL Logging: Added dedicated DDL SQL operation logging to ddl.sql file

  • ✅ Success-Only Logging: Only successful DDL operations are recorded to the SQL file

  • ✅ Timestamped Entries: Each DDL operation includes precise timestamp comments

  • ✅ Auto-Formatting: SQL statements are automatically formatted with semicolon endings

  • ✅ New Tool: Added get_ddl_sql_logs tool for querying DDL operation history

  • ✅ Enhanced Logging: Improved logging configuration with separate DDL log file support

v2.0.0

  • ✅ Initial release with DDL support

  • ✅ Permission control system

  • ✅ Operation logging

  • ✅ Connection pool management

Related MCP server: MCP MySQL Server

Features

  • ✅ SQL query execution (DDL and DML)

  • ✅ Database information retrieval

  • ✅ Operation logging

  • ✅ Connection pool management

  • ✅ Auto-reconnection mechanism

  • ✅ Health checks

  • ✅ Error handling and recovery

Installation

Global Installation (Recommended)

npm install -g @liangshanli/mcp-server-mysql

Local Installation

npm install @liangshanli/mcp-server-mysql

From Source

git clone https://github.com/liliangshan/mcp-server-mysql.git
cd mcp-server-mysql
npm install

Configuration

Set environment variables:

export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=root
export MYSQL_PASSWORD=your_password
export MYSQL_DATABASE=your_database
export READONLY=false
export ALLOW_DDL=true
export ALLOW_DROP=false
export ALLOW_DELETE=false

# Optional: Tool prefix for config isolation
export TOOL_PREFIX="projA"

# Optional: Project branding
export PROJECT_NAME="MyProject"

Usage

1. Direct Run (Global Installation)

mcp-server-mysql

2. Using npx (Recommended)

npx @liangshanli/mcp-server-mysql

3. Direct Start (Source Installation)

npm start

4. Managed Start (Recommended for Production)

npm run start-managed

Managed start provides:

  • Auto-restart (up to 10 times)

  • Error recovery

  • Process management

  • Logging

5. Development Mode

npm run dev

Editor Integration

Cursor Editor Configuration

  1. Create .cursor/mcp.json file in your project root:

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-mysql"],
      "env": {
        "MYSQL_HOST": "your_host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your_user",
        "MYSQL_PASSWORD": "your_password",
        "MYSQL_DATABASE": "your_database",
        "READONLY": "false",
        "ALLOW_DDL": "false",
        "ALLOW_DROP": "false",
        "ALLOW_DELETE": "false",
        "TOOL_PREFIX": "projA",
        "PROJECT_NAME": "MyProject"
      }
    }
  }
}

VS Code Configuration

  1. Install the MCP extension for VS Code

  2. Create .vscode/settings.json file:

{
  "mcp.servers": {
    "mysql": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-mysql"],
      "env": {
        "MYSQL_HOST": "your_host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your_user",
        "MYSQL_PASSWORD": "your_password",
        "MYSQL_DATABASE": "your_database",
        "READONLY": "false",
        "ALLOW_DDL": "false",
        "ALLOW_DROP": "false",
        "ALLOW_DELETE": "false",
        "TOOL_PREFIX": "projA",
        "PROJECT_NAME": "MyProject"
      }
    }
  }
}

Multiple MySQL Server Instances Support

You can configure multiple MySQL server instances with different TOOL_PREFIX and PROJECT_NAME to isolate tools and configurations. This is useful when you need to connect to multiple databases simultaneously.

Example: Cursor Editor Configuration

Create .cursor/mcp.json file:

{
  "mcpServers": {
    "local-mysql": {
      "disabled": false,
      "timeout": 60,
      "command": "npx",
      "args": ["@liangshanli/mcp-server-mysql"],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your_user",
        "MYSQL_PASSWORD": "your_password",
        "MYSQL_DATABASE": "your_database",
        "ALLOW_DDL": "true",
        "ALLOW_DROP": "true",
        "ALLOW_DELETE": "false",
        "TOOL_PREFIX": "local",
        "PROJECT_NAME": "local-mysql"
      }
    },
    "online-mysql": {
      "disabled": false,
      "timeout": 60,
      "command": "npx",
      "args": ["@liangshanli/mcp-server-mysql"],
      "env": {
        "MYSQL_HOST": "your_remote_host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your_user",
        "MYSQL_PASSWORD": "your_password",
        "MYSQL_DATABASE": "your_database",
        "READONLY": "true",
        "ALLOW_DDL": "false",
        "ALLOW_DROP": "false",
        "ALLOW_DELETE": "false",
        "TOOL_PREFIX": "online",
        "PROJECT_NAME": "online-mysql"
      }
    }
  }
}

Benefits of Multiple Instances:

  • Tool Isolation: Each instance has its own tool names (e.g., local_sql_query, online_sql_query)

  • Config Isolation: Logs and DDL files are stored in separate directories (e.g., ./.setting.local/, ./.setting.online/)

  • Different Permissions: Configure different permission levels for each instance (e.g., readonly for production, full access for development)

  • Project Branding: Each instance can have its own project name for better identification

Note: When using multiple instances, tools will be prefixed with TOOL_PREFIX. For example:

  • local_sql_query - queries the local database

  • online_sql_query - queries the online database (readonly)

As MCP Server

The server communicates with MCP clients via stdin/stdout after startup:

{"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {"protocolVersion": "2025-06-18"}}

Available Tools

  1. sql_query: Execute SQL queries

    {
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "sql_query",
    "arguments": {
      "sql": "SELECT * FROM users LIMIT 10"
    }
  }
}

  2. get_database_info: Get database information

    {
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_database_info",
    "arguments": {}
  }
}

  3. get_operation_logs: Get operation logs

    {
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/call",
  "params": {
    "name": "get_operation_logs",
    "arguments": {
      "limit": 50,
      "offset": 0
    }
  }
}

  4. get_ddl_sql_logs: Get DDL SQL operation logs (v2.0.1+)

    {
  "jsonrpc": "2.0",
  "id": 5,
  "method": "tools/call",
  "params": {
    "name": "get_ddl_sql_logs",
    "arguments": {
      "limit": 50,
      "offset": 0
    }
  }
}

  5. check_permissions: Check database permissions

    {
  "jsonrpc": "2.0",
  "id": 6,
  "method": "tools/call",
  "params": {
    "name": "check_permissions",
    "arguments": {}
  }
}

Connection Pool Features

  • Auto-creation: Automatically creates connection pool on notifications/initialized

  • Health checks: Checks connection pool status every 5 minutes

  • Auto-reconnection: Automatically recreates connection pool when it fails

  • Connection reuse: Uses connection pool for better performance

  • Graceful shutdown: Properly releases connections when server shuts down

Logging

General Logs

Log file location: ./.setting/mcp-mysql.log (or ./.setting.<TOOL_PREFIX>/mcp-mysql.log if TOOL_PREFIX is set)

Logged content:

  • All requests and responses

  • SQL operation records

  • Error messages

  • Connection pool status changes

DDL SQL Logs (v2.0.1+)

DDL log file location: ./.setting/ddl.sql (or ./.setting.<TOOL_PREFIX>/ddl.sql if TOOL_PREFIX is set)

Features:

  • Success-Only Recording: Only successful DDL operations are recorded

  • Timestamped Entries: Each operation includes precise timestamp comments

  • Auto-Formatting: SQL statements are automatically formatted with semicolon endings

  • Executable Format: Can be directly executed to recreate database structure

Example DDL log format:

# 2024-01-15 14:23:45
CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(100));
# 2024-01-15 14:24:12
ALTER TABLE users ADD COLUMN email VARCHAR(255);
# 2024-01-15 14:25:33
CREATE INDEX idx_email ON users(email);

DDL Logging Benefits

🔄 Database Synchronization

  • Production Sync: Easily synchronize database schema changes from development to production environments

  • Multi-Environment Deployment: Apply the same DDL changes across staging, testing, and production databases

  • Rollback Support: Maintain a complete history of schema changes for easy rollback operations

📋 Development Workflow

  • Schema Versioning: Track database evolution with timestamped change history

  • Team Collaboration: Share database structure changes with team members through executable SQL files

  • Code Review: Review database changes alongside application code changes

🛡️ Operational Excellence

  • Audit Trail: Maintain comprehensive audit logs of all database structure modifications

  • Compliance: Meet regulatory requirements for database change tracking

  • Disaster Recovery: Quickly rebuild database structure from DDL logs in case of data loss

⚡ Performance & Reliability

  • Clean Execution: Only successful operations are recorded, ensuring reliable script execution

  • Error Prevention: Failed operations are excluded, preventing script execution errors

  • Automated Formatting: Consistent SQL formatting reduces manual errors and improves readability

Error Handling

  • Individual request errors don't affect the entire server

  • Connection pool errors are automatically recovered

  • Process exceptions are automatically restarted (managed mode)

Environment Variables

Variable

Default

Description

MYSQL_HOST

localhost

MySQL host address

MYSQL_PORT

3306

MySQL port

MYSQL_USER

root

MySQL username

MYSQL_PASSWORD

MySQL password

MYSQL_DATABASE

Database name

READONLY

false

If set to 'true', only SELECT and SHOW commands are allowed. This check has the highest priority and overrides all other permission settings

ALLOW_DDL

false

Whether to allow DDL operations (CREATE, ALTER, TRUNCATE, RENAME, COMMENT). Set to 'true' to enable

ALLOW_DROP

false

Whether to allow DROP operations. Set to 'true' to enable

ALLOW_DELETE

false

Whether to allow DELETE operations. Set to 'true' to enable

TOOL_PREFIX

Optional tool prefix for tool names and config isolation. Example: export TOOL_PREFIX="projA"

PROJECT_NAME

Optional project branding for tool descriptions

MCP_LOG_DIR

./.setting (or ./.setting. if TOOL_PREFIX is set)

Log directory

MCP_LOG_FILE

mcp-mysql.log

Log filename

MCP_DDL_LOG_FILE

ddl.sql

DDL SQL log filename (v2.0.1+)

Development

Project Structure

mcpmysql/
├── src/
│   └── server-final.js    # Main server file
├── start-server.js        # Managed startup script
├── package.json
└── README.md

Testing

npm test

Quick Start

1. Install Package

npm install -g @liangshanli/mcp-server-mysql

2. Configure Environment Variables

export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=root
export MYSQL_PASSWORD=your_password
export MYSQL_DATABASE=your_database
export READONLY=false
export ALLOW_DDL=false
export ALLOW_DROP=false
export ALLOW_DELETE=false

Permission Control Examples:

# Readonly mode: Only SELECT and SHOW commands allowed (highest priority)
export READONLY=true

# Default: Disable all destructive operations (safe mode)
export READONLY=false
export ALLOW_DDL=false
export ALLOW_DROP=false
export ALLOW_DELETE=false

# Allow DDL but disable DROP and DELETE
export READONLY=false
export ALLOW_DDL=true
export ALLOW_DROP=false
export ALLOW_DELETE=false

# Allow everything except DELETE
export READONLY=false
export ALLOW_DDL=true
export ALLOW_DROP=true
export ALLOW_DELETE=false

# Enable all operations (use with caution)
export READONLY=false
export ALLOW_DDL=true
export ALLOW_DROP=true
export ALLOW_DELETE=true

3. Run Server

mcp-server-mysql

License

MIT

Available Tools

5 tools
check_permissionsA

Check database permissions for DDL, DROP, DELETE and other operations. Returns detailed permission status including readonly mode restrictions (only SELECT and SHOW allowed when readonly is enabled)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses that readonly mode restricts to SELECT and SHOW, and returns detailed permission status. However, it does not explicitly state that the tool is read-only or requires no special privileges.

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?

Two sentences, front-loaded with purpose, followed by a key detail. Every word earns its place; no redundancy or filler.

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

Completeness3/5

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

Given no output schema, the description provides a high-level idea of the return value ('detailed permission status including readonly mode restrictions') but lacks specifics on format or full scope. It is adequate for a simple tool but could be more complete.

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?

No parameters exist, and the description adds meaning by explaining that the tool returns permission status including readonly restrictions. Baseline for 0 parameters is 4, and the description fulfills that.

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 verb 'check' and resource 'database permissions', specifying operations like DDL, DROP, DELETE. It distinguishes from siblings like sql_query or get_database_info by focusing on permission status.

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

Usage Guidelines3/5

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

The description implies use for checking permissions, especially regarding readonly mode, but lacks explicit guidance on when to use versus alternatives like sql_query or get_operation_logs. No when-not or alternative recommendations.

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

get_database_infoA

Get database information, including database list, table list and configuration information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It claims read-only behavior ('Get') but does not confirm idempotency, performance impact, or whether it can be called without side effects. No mention of authentication requirements or data freshness.

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 a single concise sentence that front-loads the main purpose. Every word contributes meaning, and there is no redundancy or clutter.

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

Completeness3/5

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

Although there are no parameters and no output schema, the description lists three categories of information. However, it lacks detail on the format or granularity of each (e.g., are database names just strings? Is configuration a key-value list?). For a tool with no other documentation, this leaves ambiguity.

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?

The tool has zero parameters, so schema coverage is 100%. The description adds value beyond the schema by explaining the nature of the output (database list, table list, configuration). This compensates for the absence of parameter documentation, exceeding the baseline of 3.

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 action ('Get') and resource ('database information'), and enumerates specific types of information returned (database list, table list, configuration info). It is distinct from sibling tools which focus on permissions, logs, and queries.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage for retrieving general database metadata, but fails to specify conditions or when not to use it (e.g., for specific table schemas). Sibling tools are named but not contrasted.

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

get_ddl_sql_logsC

Get DDL SQL operation logs

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoLimit count, default 50, max 500
offsetNoOffset, default 0

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are provided, and the description only states 'Get DDL SQL operation logs' without disclosing behavioral traits like read-only nature, authorization needs, error behavior, or output format. The description fails to compensate for the lack of annotations.

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

Conciseness3/5

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

The description is very short (4 words) and no words are wasted. However, it is too concise and lacks necessary details, making it less useful than it could be.

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

Completeness2/5

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

Given the tool has no output schema and no annotations, the description is too brief to fully inform an agent. It does not explain what DDL SQL operation logs are, how they are filtered, or what the output looks like.

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 input schema has 100% description coverage for both parameters (limit, offset) with defaults and max constraints. The description adds no extra meaning beyond what is already in the schema, so baseline 3 is appropriate.

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 states the verb 'Get' and the resource 'DDL SQL operation logs'. It clearly identifies the tool's function and implicitly distinguishes from siblings like get_operation_logs by specifying DDL, though it does not explicitly differentiate.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, such as get_operation_logs or sql_query. There is no mention of prerequisites or context.

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

get_operation_logsC

Get operation logs

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoLimit count, default 50
offsetNoOffset, default 0

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states 'Get', implying a read operation, but does not mention any side effects, limitations, or prerequisites. The minimal description adds no transparency.

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

Conciseness2/5

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

The description is extremely concise (3 words) but under-specified. It does not earn its place because it adds no value over the tool name, making it too minimal for effective guidance.

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

Completeness2/5

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

Given no output schema and two parameters, the description should clarify the nature and scope of operation logs. It fails to do so, leaving ambiguity especially compared to sibling 'get_ddl_sql_logs'.

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?

Schema coverage is 100% with both limit and offset described. The description adds no parameter meaning beyond what the schema provides, so baseline 3 is appropriate.

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

Purpose3/5

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

The description 'Get operation logs' restates the tool name, indicating a read operation on logs. It is clear but generic, failing to differentiate from sibling 'get_ddl_sql_logs' or specify what 'operation logs' entail.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like check_permissions or get_ddl_sql_logs. The description offers no usage context or exclusions.

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

sql_queryC

Execute SQL query, supports DDL and DML operations

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesSQL statement to execute

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden. It mentions support for DDL (destructive) and DML (data modification) but fails to disclose potential side effects like table locking, long-running queries, or required permissions. This is insufficient for safe agent usage.

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

Conciseness4/5

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

The description is a single, front-loaded sentence that efficiently states the purpose. It is concise, but additional critical information (e.g., output format) is missing, preventing a higher score.

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

Completeness2/5

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

Despite having only one parameter and no nested objects, the description lacks output schema details and fails to inform the agent about what the tool returns (e.g., rows, affected count). Sibling tools hint at related functionality, but the description is too sparse for a generic SQL executor.

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 single parameter 'sql' is fully described in the input schema (100% coverage). The tool description does not add any additional semantics or constraints beyond the schema, so baseline score of 3 is appropriate.

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 'Execute SQL query' and specifies support for DDL and DML operations, which distinguishes it from read-only or log retrieval sibling tools. However, it could be more precise about the exact types of SQL statements allowed (e.g., SELECT, INSERT, etc.).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool vs. siblings like check_permissions or get_database_info. There is no mention of prerequisites, authorization, or context such as needing to validate permissions before execution.

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.

  1. 5 tool updatesv3.1.1
    • First observedcheck_permissions
    • First observedget_database_info
    • First observedget_ddl_sql_logs
    • First observedget_operation_logs
    • First observedsql_query
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation4/5

Most tools have distinct purposes, but 'get_ddl_sql_logs' and 'get_operation_logs' overlap, as DDL logs are a subset of operation logs. This may cause confusion.

Naming Consistency3/5

Three tools follow the 'get_' prefix pattern, but 'check_permissions' uses 'check_' and 'sql_query' is a noun-verb inversion, breaking consistency.

Tool Count5/5

Five tools cover essential database operations (permissions, info, query, logs) without unnecessary bloat, well-scoped for a MySQL server.

Completeness4/5

Core operations are covered via sql_query for DDL/DML and get_database_info for browsing. Missing explicit user management tools, but sql_query can compensate.

Maintenance

ActivityInactive
ResponsivenessSlow

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • mysql-mcp

    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.
    1,081
    MIT

  • MCP MySQL Server

    BobLiu1996
    F
    license
    Not graded
    quality
    D
    maintenance
    A MySQL MCP server with DDL support, permission control, and operation logging, enabling SQL query execution, database info retrieval, and schema management.
    -

  • MySQL Ops MCP

    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.
    1
    -

Latest Blog Posts

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/liliangshan/mcp-server-mysql'

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