What can you do with this server?

easy-mysql-mcp is a MySQL database interface server providing an MCP interface for AI assistants to inspect, query, and modify a MySQL database through the following tools: * mysql_query: Execute read-only SELECT statements for data retrieval. * mysql_execute: Execute data modification statements (INSERT, UPDATE, DELETE) with optional parameterized inputs. * explain_query: Run EXPLAIN on a SQL query to analyze its execution plan. * list_tables: List all base tables with approximate row counts and comments. * list_views: List all views in the current database. * describe_table: Show column schema/structure for one or more tables. * describe_index: Show indexes defined on a specific table. * list_triggers: List all triggers in the current database. * get_current_privileges: Check the current MySQL user's permissions and grants. Database connection is configurable via environment variables.

Which integrations are available for this server?

Allows AI assistants to inspect and query a MySQL database through a safe, structured tool interface, including schema discovery, query execution, and privilege inspection.

How do I use easy-mysql-mcp?

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., "@easy-mysql-mcp describe the users 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

easy-mysql-mcp

by chenkumi

Overview Schema Related Servers Score Discussions

TypeScript

Local

easy-mysql-mcp

A lightweight Model Context Protocol (MCP) server that lets AI assistants inspect and query a MySQL database through a safe, structured tool interface.

This project uses Node.js, TypeScript, the official MCP SDK, and mysql2/promise. It runs over stdio, so it can be used directly by MCP clients such as Claude Desktop.

Features

MySQL connection pooling powered by mysql2/promise
Read-only query tool for data retrieval
Execute tool for data modification statements
Batch execution and CSV import/export helpers
Schema discovery tools for tables, views, indexes, and triggers
Query plan inspection with EXPLAIN
Current user and privilege inspection

Related MCP server: MCP MySQL Server

Requirements

Node.js 20 or newer
npm
A reachable MySQL-compatible database

Installation

Run the server directly with npx:

npx -y easy-mysql-mcp

For local development after cloning the repository:

cd easy-mysql-mcp
npm install
npm run build

Configuration

Configure the server with environment variables. You can provide them through your MCP client configuration or by creating a local .env file.

Variable	Required	Default	Description
`MYSQL_HOST`	Yes	-	MySQL host name or IP address
`MYSQL_PORT`	No	`3306`	MySQL port
`MYSQL_USER`	Yes	-	MySQL user name
`MYSQL_PASSWORD`	Yes	-	MySQL password
`MYSQL_DATABASE`	Yes	-	Default database/schema
`MYSQL_CONNECTION_LIMIT`	No	`10`	Maximum number of active pool connections
`MYSQL_MAX_IDLE`	No	`10`	Maximum number of idle pool connections
`MYSQL_IDLE_TIMEOUT`	No	`60000`	Idle connection timeout in milliseconds
`MYSQL_QUEUE_LIMIT`	No	`0`	Maximum queued connection requests, where `0` means unlimited
`MYSQL_WAIT_FOR_CONNECTIONS`	No	`true`	Whether the pool waits when all connections are busy
`MYSQL_ENABLE_KEEP_ALIVE`	No	`true`	Whether TCP keep-alive is enabled
`MYSQL_KEEP_ALIVE_INITIAL_DELAY`	No	`0`	Initial TCP keep-alive delay in milliseconds
`MYSQL_READ_ONLY`	No	`false`	When `true`, enables read-only mode and does not register `mysql_execute`
`MYSQL_MCP_MODE`	No	`readwrite`	MCP policy mode. Use `readonly` to disable write execution or `advanced` to enable schema modification tools
`MYSQL_MCP_ALLOW_TABLES`	No	-	Comma-separated table allowlist, such as `users,orders`
`MYSQL_MCP_DENY_TABLES`	No	-	Comma-separated table denylist, such as `payments,secrets`
`MYSQL_BATCH_MAX_SIZE`	No	`100`	Maximum number of parameter sets per internal batch for `mysql_batch_execute`
`MYSQL_LOG_PATH`	No	`logs`	Directory used for batch execution and CSV import log files
`MYSQL_POLICY_HOOK`	No	-	HTTP POST URL for external accept/reject/approval policy decisions
`MYSQL_APPROVAL_TTL_SECONDS`	No	`300`	Number of seconds a pending approval remains valid

Example .env:

MYSQL_HOST=localhost
MYSQL_PORT=3306
MYSQL_USER=root
MYSQL_PASSWORD=your_password
MYSQL_DATABASE=your_database

Usage

Configure your MCP client to launch the package through npx.

For local development, build the TypeScript source first:

npm run build

Start the MCP server:

npm start

The server communicates over stdio and is normally launched by an MCP client rather than run manually.

If you are unsure how a tool should be used, or an operation fails, call mysql_manual first. It returns the built-in manual with safe usage rules, parameter binding guidance, and SQL composition notes.

Claude Desktop Example

{
  "mcpServers": {
    "easy-mysql-mcp": {
      "command": "npx",
      "args": ["-y", "easy-mysql-mcp"],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "YOUR USERNAME",
        "MYSQL_PASSWORD": "YOUR PASSWORD",
        "MYSQL_DATABASE": "YOUR DB NAME"
      }
    }
  }
}

Restart Claude Desktop after updating the configuration.

Codex config.toml Example

[mcp_servers.easy-mysql-mcp]
args = ["-y", "easy-mysql-mcp"]
command = "npx"
enabled = true

[mcp_servers.easy-mysql-mcp.env]
MYSQL_HOST = "localhost"
MYSQL_PORT = "3306"
MYSQL_USER = "YOUR USERNAME"
MYSQL_PASSWORD = "YOUR PASSWORD"
MYSQL_DATABASE = "YOUR DB NAME"

OpenCode opencode.jsonc Example

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "easy-mysql-mcp": {
      "type": "local",
      "command": ["npx", "-y", "easy-mysql-mcp"],
      "enabled": true,
      "environment": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "YOUR USERNAME",
        "MYSQL_PASSWORD": "YOUR PASSWORD",
        "MYSQL_DATABASE": "YOUR DB NAME",
      },
    },
  },
}

Available Tools

Tool	Description
`mysql_manual`	Return the built-in manual. Use this first when you are unsure how to use MySQL tools or need help diagnosing an operation error
`mysql_query`	Execute a SQL query intended for data retrieval, such as `SELECT`
`mysql_execute`	Execute a data modification statement, such as `INSERT`, `UPDATE`, or `DELETE`
`mysql_schema_execute`	Execute schema modification statements in advanced mode, such as `CREATE TABLE`, `ALTER TABLE`, `CREATE VIEW`, `CREATE TRIGGER`, and `CREATE INDEX`
`mysql_batch_execute`	Execute one data modification statement repeatedly with multiple parameter sets
`mysql_import_csv`	Import a UTF-8 CSV file into a table using the header row as column names
`mysql_export_csv`	Export all rows from a table to a UTF-8 CSV file
`explain_query`	Run `EXPLAIN` for a SQL query and return the execution plan
`list_tables`	List base tables in the current database, including approximate row counts and comments
`list_views`	List views in the current database
`describe_table`	Show column information for one or more tables
`describe_index`	Show indexes for a table
`list_triggers`	List triggers in the current database
`get_current_privileges`	Show the current MySQL user and grants
`mysql_run_approved_command`	Run a pending command after approval, only registered when `MYSQL_POLICY_HOOK` is set
`mysql_list_pending_approvals`	List pending approval requests, only registered when `MYSQL_POLICY_HOOK` is set
`mysql_cancel_approval`	Cancel a pending approval request, only registered when `MYSQL_POLICY_HOOK` is set

When MYSQL_READ_ONLY=true or MYSQL_MCP_MODE=readonly, the mysql_execute, mysql_batch_execute, and mysql_import_csv tools are not registered.

When MYSQL_MCP_MODE=advanced, mysql_schema_execute is registered. Existing write tools remain available because advanced mode includes read/write behavior.

Batch Execute

mysql_batch_execute runs the same parameterized write statement with multiple parameter arrays. It is useful for bulk inserts or repeated updates without enabling multi-statement SQL.

Example input:

{
  "sql": "INSERT INTO users (name, email) VALUES (?, ?)",
  "paramsList": [
    ["Alice", "alice@example.com"],
    ["Bob", "bob@example.com"]
  ],
  "transaction": "all"
}

The transaction option controls transaction scope:

Value	Behavior
`all`	Default. Wrap all rows in one transaction
`batch`	Wrap each internal batch in its own transaction
`each`	Wrap each parameter set in its own transaction
`none`	Do not start explicit transactions

The server splits paramsList into internal batches using MYSQL_BATCH_MAX_SIZE. For example, with the default size of 100, 250 parameter sets run as 100, 100, and 50.

Detailed per-row execution results are written to a timestamped .log file under MYSQL_LOG_PATH, which defaults to logs/. The tool response only returns summary counts and the log file path. Log files older than seven days are cleaned up automatically when the server starts.

CSV Import and Export

mysql_import_csv reads a UTF-8 CSV file and inserts rows into a table. The first CSV row must contain column names, and every data row must have the same number of columns. Internally, the tool builds a parameterized INSERT statement and executes it through the same batch execution path as mysql_batch_execute.

Example import input:

{
  "tableName": "users",
  "filePath": "./data/users.csv",
  "transaction": "all"
}

mysql_export_csv exports all rows from a table to a UTF-8 CSV file. It writes a header row using the table's column names, even when the table has no rows.

Example export input:

{
  "tableName": "users",
  "filePath": "./exports/users.csv"
}

CSV import/export uses standard comma-separated CSV with double-quote escaping. Empty CSV fields are imported as empty strings.

SQL Policy

The server applies a lightweight SQL policy before executing user-provided SQL:

mysql_query allows only single-statement SELECT, SHOW, DESCRIBE, and EXPLAIN queries.
explain_query accepts only a single SELECT statement and runs EXPLAIN for it.
mysql_execute allows only single-statement INSERT, UPDATE, DELETE, and REPLACE statements when write mode is enabled.
mysql_schema_execute is only registered when MYSQL_MCP_MODE=advanced, and allows single-statement schema changes for tables, views, triggers, and indexes.
mysql_batch_execute uses the same SQL policy as mysql_execute and applies the statement repeatedly with parameter arrays.
mysql_import_csv uses table policy and the same batch execution path as mysql_batch_execute.
mysql_export_csv uses table policy before exporting table data.
Multi-statement SQL is rejected.
CREATE TABLE ... AS SELECT is rejected because it copies data while creating a table.
SELECT ... INTO and locking reads are rejected for read-query tools.
MYSQL_MCP_DENY_TABLES rejects matching tables before MYSQL_MCP_ALLOW_TABLES is evaluated.
If MYSQL_MCP_ALLOW_TABLES is set, every detected table must be included in the allowlist.

Table policy matching is best-effort and based on SQL parsing. You can use either table or database.table entries. MySQL grants remain the final security boundary.

Policy Order

Policy checks run in this order:

Built-in SQL safety checks run first, such as single-statement enforcement and allowed statement types for each tool.
MYSQL_MCP_DENY_TABLES is checked next. If a detected table matches the denylist, the command is rejected immediately.
MYSQL_MCP_ALLOW_TABLES is checked after the denylist. If an allowlist is configured, every detected table must be included in it.
MYSQL_POLICY_HOOK runs only after the built-in SQL policy and table allow/deny policy pass.

If both MYSQL_MCP_ALLOW_TABLES and MYSQL_MCP_DENY_TABLES are configured, the denylist takes precedence. For example:

MYSQL_MCP_ALLOW_TABLES=users,orders,payments
MYSQL_MCP_DENY_TABLES=payments

In this configuration, users and orders are allowed, payments is rejected, and all other tables are rejected because they are not in the allowlist.

MYSQL_POLICY_HOOK cannot override built-in rejections. It can only decide what happens after a command has already passed local policy: accept, reject, or approval_required.

Advanced Schema Mode

Set MYSQL_MCP_MODE=advanced to enable mysql_schema_execute for schema changes. This is an explicit opt-in mode for database structure operations.

Allowed schema statements:

Object	Statements
Tables	`CREATE TABLE`, `ALTER TABLE`, `DROP TABLE`, `RENAME TABLE`
Views	`CREATE VIEW`, `CREATE OR REPLACE VIEW`, `DROP VIEW`
Triggers	`CREATE TRIGGER`, `DROP TRIGGER`
Indexes	`CREATE INDEX`, `DROP INDEX`, plus index changes through `ALTER TABLE`

The same table allow/deny policy applies to detected schema objects and referenced tables. MYSQL_MCP_DENY_TABLES still takes precedence over MYSQL_MCP_ALLOW_TABLES.

Advanced mode still rejects multi-statement SQL, unsupported DDL object types, and CREATE TABLE ... AS SELECT.

Policy Hook and Approvals

When MYSQL_POLICY_HOOK is configured, the server posts each tool action to the hook after built-in policy checks pass and before the command runs.

Example hook request:

{
  "functionName": "mysql_execute",
  "sql": "UPDATE users SET email = ? WHERE id = ?",
  "statementType": "update",
  "tableNames": ["users"],
  "paramsPreview": ["new@example.com", 123],
  "metadata": {
    "database": "app_db",
    "mode": "readwrite",
    "timestamp": "2026-05-20T12:00:00.000Z"
  }
}

The hook must return one of:

{ "status": "accept" }

{ "status": "reject", "message": "Writes are blocked outside maintenance windows." }

{
  "status": "approval_required",
  "message": "User approval is required before updating users."
}

For approval_required, the server does not execute the command. It stores the original pending command in memory and returns an approval_required response with a server-generated approvalId. The hook does not provide the approval id. After the MCP host obtains user approval, it can call:

{
  "approvalId": "apv_..."
}

with mysql_run_approved_command. Pending approvals are one-time use and expire after MYSQL_APPROVAL_TTL_SECONDS. mysql_list_pending_approvals and mysql_cancel_approval are also available while MYSQL_POLICY_HOOK is set.

This is an approval-friendly protocol. The server cannot verify that a human approved the action; the MCP host or external platform is responsible for presenting the approval request to a user.

Security Notes

Use a dedicated MySQL user with the minimum permissions your assistant needs.
Prefer read-only database credentials if you only need inspection and reporting.
Use MYSQL_READ_ONLY=true or MYSQL_MCP_MODE=readonly to hide write execution from MCP clients.
Use MYSQL_MCP_MODE=advanced only when the assistant should be able to modify schema objects such as tables, views, triggers, and indexes.
Use MYSQL_MCP_ALLOW_TABLES and MYSQL_MCP_DENY_TABLES as MCP-level guardrails, not as a replacement for MySQL grants.
Use MYSQL_POLICY_HOOK when you need an external policy or approval workflow.
Be careful with mysql_execute, because it can modify data.
Be careful with mysql_schema_execute, because it can create, alter, or drop database structure.
Be careful with mysql_import_csv, because it can insert many rows.
Batch execution and CSV import logs include parameter values and per-row results. Treat files under MYSQL_LOG_PATH as sensitive.
CSV export writes table data to the local filesystem. Treat exported files as sensitive.
Multi-statement SQL is disabled in the MySQL client configuration.
Do not commit .env files or real database credentials to GitHub.
Review generated SQL before running it against production data.

Development

npm run dev

This runs TypeScript in watch mode.

To create a production build:

npm run build

To run the integration test suite, configure a test database in .env:

TEST_HOST=localhost
TEST_PORT=3306
TEST_USERNAME=test_user
TEST_PASSWORD=test_password
TEST_DB=test_database

Then run:

npm run test

The tests create and drop temporary tables, a view, and a trigger in TEST_DB. If the TEST_* variables are missing, the integration test is skipped.

Project Structure

src/
  config.ts   Environment-driven MCP policy configuration
  csv.ts      CSV parsing and writing helpers
  csvTools.ts CSV import/export tool implementations
  db.ts       MySQL pool and query helpers
  index.ts    MCP server and tool registration
  logs.ts     Batch execution log helpers
  policyHook.ts External policy hook client and approval response helpers
  sqlPolicy.ts SQL parsing and policy enforcement
  toolHandlers.ts Shared tool handler implementations
  approvalStore.ts In-memory pending approval store

License

MIT. See LICENSE.md.

Available Tools

9 tools

describe_indexB

Show indexes for a specific table.

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes	The name of the table to show indexes for.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Does not disclose what types of indexes are shown, return format, or any limitations.

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?

One short sentence, no unnecessary words. Could benefit from slightly more detail without harming conciseness.

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?

No output schema; description should provide more context about returned data or behavior, but doesn't.

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 covers single parameter 'table' with clear description. No additional context needed.

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 the action (show indexes) and resource (specific table). Distinguishes from siblings like describe_table (table structure) and list_tables (table list).

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 on when to use this tool versus alternatives like describe_table or explain_query. No prerequisites or context about when indexing info is needed.

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

describe_tableB

Show the schema/structure of one or more specific tables.

ParametersJSON Schema

Name	Required	Description	Default
`tables`	Yes	The names of the tables to describe.

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for behavior. It only states it shows schema/structure, but does not disclose that it is read-only, how it handles missing tables, or any performance considerations.

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?

Single sentence, no wasted words. However, it could be slightly more informative without becoming verbose.

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 only one parameter, the description fails to explain what the output looks like or any constraints. It is minimal and leaves the agent guessing about return structure.

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 description coverage is 100%, so baseline is 3. The description adds no additional information about the 'tables' parameter beyond what the schema already provides ('The names of the tables to describe').

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 shows schema/structure of tables, using specific verb 'Show' and resource 'tables'. It distinguishes from siblings like describe_index and list_tables by focusing on structure.

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 on when to use this tool versus alternatives like describe_index (for indexes) or explain_query (for query plans). The description does not mention exclusions or prerequisites.

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

explain_queryA

Run EXPLAIN on a SQL query to analyze its execution plan and performance.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The SQL query to explain.

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes the action as 'analyze execution plan' which implies read-only, but does not explicitly state it is non-destructive or disclose any behavioral traits like side effects or auth requirements. Adequate but lacks explicitness.

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 sentence that clearly states the action and purpose. It is front-loaded and contains no unnecessary words.

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 the tool's simplicity (one parameter, no output schema), the description is mostly complete. However, it could mention that the output is an execution plan and that it is a read-only operation. Without output schema, a hint about return value would improve completeness.

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% and the description's mention of 'SQL query' mirrors the schema parameter description. The description adds no additional meaning 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.

Purpose5/5

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

The description clearly states the action ('Run EXPLAIN'), the resource ('SQL query'), and the purpose ('analyze its execution plan and performance'). It distinguishes from siblings like mysql_execute (which runs the query) and mysql_query (returns results).

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 performance analysis but does not explicitly state when to use this tool over alternatives or provide when-not-to-use guidance. No comparison to sibling tools is given.

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

get_current_privilegesA

Check the permissions and grants of the current database user. Useful for debugging access issues.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It correctly indicates a read operation (checking permissions) but does not disclose any additional behavioral traits (e.g., required permissions, performance impact).

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 concise sentences with zero wasted words. Every sentence adds value: first states purpose, second gives typical usage context.

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 the tool has no parameters and no output schema, the description is adequate for basic understanding but lacks details about the return format or potential errors, which would enhance completeness.

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% (no parameters), so baseline is 3. The description does not need to add parameter-level detail, and it doesn't, but it also doesn't enrich understanding of the tool's behavior beyond the schema.

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?

Clear verb 'Check' and specific resource 'permissions and grants of the current database user'. Distinct from sibling tools like describe_table or mysql_query which deal with other aspects.

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?

Explicitly states 'Useful for debugging access issues', providing clear context for appropriate use. Does not mention when not to use or alternatives, but this is sufficient for a simple read-only tool.

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

list_tablesA

List all base tables in the current database with row counts and comments.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

Without annotations, the description carries the burden of behavioral context. It states the output includes row counts and comments but does not specify whether row counts are approximate, whether system tables are excluded, or any access requirements. Some transparency is present but incomplete.

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 sentence containing 12 words with no fluff. Every word earns its place.

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

Completeness4/5

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

For a zero-parameter tool with no output schema and no annotations, the description covers the essential behavior. However, it could be more complete by specifying whether tables from all schemas are listed or just the current schema, and whether row counts are real-time or cached. Still, it is largely adequate.

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?

There are no parameters, and schema description coverage is 100%. The description adds no param info because none is needed. Baseline 4 is appropriate.

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 uses a specific verb ('List') and resource ('base tables') and includes additional details ('with row counts and comments'). It clearly distinguishes itself from siblings like 'describe_table' (which describes a single table) and 'list_views' (lists views).

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 provides no explicit guidance on when to use this tool versus alternatives like 'describe_table' or 'list_views'. It implies usage for listing tables but does not mention when not to use it or which sibling to choose in specific scenarios.

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

list_triggersA

List all triggers in the current database.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only or if there are any side effects. For a list operation, it likely is harmless, but this is not stated.

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 sentence that is perfectly concise and front-loaded with the action and resource. No unnecessary words.

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

Completeness4/5

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

Given the low complexity (no parameters, no output schema), the description is sufficient to understand what the tool does. It could mention what the returned list contains (e.g., trigger names/details), but it is not required for basic use.

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 tool has zero parameters, and the input schema is empty. The description adds no additional meaning beyond the schema, which is already fully documented by its absence. Baseline of 3 is appropriate.

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 uses 'List' as a specific verb and 'triggers' as the resource, with scope 'current database'. It clearly distinguishes from sibling tools like list_tables and list_views.

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 a straightforward use case but provides no explicit guidance on when to use this tool versus alternatives (e.g., describe_table for metadata). No exclusions or context are given.

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

list_viewsA

List all views in the current database.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so the description must fully disclose behavior. It only states 'List all views' without specifying that it is read-only, whether results are ordered, paginated, or what form the list takes. Minimal transparency for a potentially resource-consuming operation.

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?

Single, clear sentence with no extraneous words. Perfectly concise and structured for quick comprehension.

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 should indicate what the list contains (e.g., names only). It does not, leaving ambiguity. However, for a straightforward listing tool with zero parameters, the description is minimally adequate 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?

Zero parameters and schema coverage is 100% (vacuously). Per calibration, 0 parameters gives baseline 4. The description adds no parameter info, but none is needed.

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 the verb 'List' and resource 'views' with scope 'all views in the current database'. Differentiated from siblings that focus on tables, indexes, queries, etc.

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 versus alternatives, though the sibling tools cover different database objects, making usage contextually implied. Lacks any 'when not to use' or alternative references.

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

mysql_executeC

Execute a data modification SQL statement (e.g., INSERT, UPDATE, DELETE).

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The SQL statement to execute.
`params`	No	Optional parameters for the statement.

TDQS

C2.9/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 the basic function without disclosing behavior such as transaction handling, permission requirements, or potential side effects. The description does not 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.

Conciseness4/5

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

The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded with the verb 'Execute'. While brief, it wastes no words.

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 presence of sibling tools like `mysql_query`, the description fails to differentiate use cases. It also does not specify return values (no output schema) or any additional context that would help an agent select this tool over others.

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 already describes both parameters (`sql` and `params`) with 100% coverage. The description adds no additional semantic information about the parameters, so it meets the baseline but does not go beyond.

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 indicates the tool executes data modification SQL statements and provides examples (INSERT, UPDATE, DELETE), making the purpose obvious. However, it does not explicitly distinguish from the sibling tool `mysql_query`, which likely handles read queries.

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 given on when to use this tool versus alternatives like `mysql_query` or `explain_query`. There are no explicit context, prerequisites, or exclusions mentioned.

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

mysql_queryA

Execute a read-only SQL query (e.g., SELECT). Use this for data retrieval.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The SQL query to execute.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, description carries the burden. It explicitly states 'read-only', which is a critical behavioral trait, but does not mention potential errors, auth requirements, or return format.

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?

Single sentence with no unnecessary words, front-loading the core purpose and usage context.

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

Completeness4/5

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

For a simple read-only query tool with one parameter and no output schema, the description is adequate. It covers the essential constraint (read-only) and usage scenario.

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?

Input schema has 100% coverage for the single parameter 'sql' with description. Description adds no extra meaning beyond 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.

Purpose5/5

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

Description clearly states the tool executes a read-only SQL query for data retrieval, and the sibling mysql_execute implies write operations, distinguishing it effectively.

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?

Description specifies 'read-only' and 'use for data retrieval', implying it should not be used for mutations, but does not explicitly mention alternatives or when not to use.

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

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: describing indexes vs tables, explaining queries, checking privileges, listing various objects, executing vs querying SQL. No two tools overlap in functionality.

Naming Consistency3/5

Tools mostly follow a verb_noun pattern, but there's inconsistency: some use 'mysql_' prefix (mysql_execute, mysql_query) while others use direct verbs (describe_table, list_tables). This mix is not chaotic but lacks uniformity.

Tool Count5/5

With 9 tools covering listing, describing, querying, executing, and explaining, the count is well-scoped for a MySQL management server. Each tool adds clear value without redundancy.

Completeness3/5

The set covers introspection and DML operations well, but lacks dedicated tools for DDL operations like CREATE, ALTER, or DROP. mysql_execute is described for DML only, so creating tables or indexes is not directly supported.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

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

QueryBear
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
wgong-sqlite-mcp-server
ai.smithery
Explore, query, and inspect SQLite databases with ease. List tables, preview results, and view det…
Databases Developer Tools
21
mcpmyadmin
ai.mcpmyadmin
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Databases Security
2
datamcp — Hosted Model Context Protocol for Databases, APIs, and Agent Memory
io.github.mironovisa
PostgreSQL, MySQL, OpenAPI/Swagger, and shared Agent Memory with scoped access.
Databases Security Developer Tools
3

Related MCP Servers

MySQL MCP Server
Databases Security Developer Tools
amornpan
F
license
Not graded
quality
D
maintenance
Enables secure interaction with MySQL databases, allowing AI assistants to list tables, read data, and execute SQL queries through a controlled interface.
Updated a year ago (2025-03-07 07:21 UTC)
MCP MySQL Server
Databases Developer Tools
Iceeeeec
A
license
Not graded
quality
D
maintenance
Enables AI assistants to safely query MySQL databases with read-only access by default, supporting table listing, structure inspection, and SQL queries with optional write operation control.
Updated 10 months ago (2025-11-06 03:02 UTC)
18
MIT
MySQL ReadOnly MCP Server
Databases Developer Tools
zhaojw-php
A
license
A
quality
D
maintenance
Enables AI assistants to safely query MySQL databases with read-only access, featuring SQL injection protection, connection pooling, and automatic query limits for secure database exploration.
Updated 9 months ago (2025-12-08 01:56 UTC)
4
66
MIT
MySQL MCP Server
Databases Developer Tools
za2keep
A
license
Not graded
quality
Not graded
maintenance
Enables AI assistants to securely interact with MySQL databases through tools for query execution, schema inspection, and transaction management. It features built-in safety controls like row limits and query validation to ensure safe and standardized database access.
Updated 7 months ago (2026-01-28 03:58 UTC)
454

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/chenkumi/easy-mysql-mcp'

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