Skip to main content
Glama
enesjakozh
dpflucas

MySQL Database Access

by dpflucas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

npmバージョン 鍛冶屋のバッジ

MySQLデータベースアクセスMCPサーバー

このMCPサーバーは、MySQLデータベースへの読み取り専用アクセスを提供します。これにより、以下のことが可能になります。

  • 利用可能なデータベースの一覧

  • データベース内のテーブルを一覧表示する

  • テーブルスキーマを説明する

  • 読み取り専用SQLクエリを実行する

セキュリティ機能

  • 読み取り専用アクセス: SELECT、SHOW、DESCRIBE、および EXPLAIN ステートメントのみが許可されます

  • クエリ検証: SQLインジェクションを防ぎ、データ変更の試みをブロックします

  • クエリタイムアウト: 長時間実行されるクエリがリソースを消費するのを防ぎます

  • 行制限: 過剰なデータ返送を防止

Related MCP server: mysql-mcp-server

インストール

1. 次のいずれかの方法でインストールします。

NPMからインストール

# Install globally
npm install -g mysql-mcp-server

# Or install locally in your project
npm install mysql-mcp-server

ソースからビルド

# Clone the repository
git clone https://github.com/dpflucas/mysql-mcp-server.git
cd mysql-mcp-server

# Install dependencies and build
npm install
npm run build

Smithery経由でインストール

Smithery経由で Claude AI 用の MySQL データベース アクセス MCP サーバーを自動的にインストールするには:

npx -y @smithery/cli install @dpflucas/mysql-mcp-server --client claude

2. 環境変数を設定する

サーバーには次の環境変数が必要です。

  • MYSQL_HOST : データベースサーバーのホスト名

  • MYSQL_PORT : データベースサーバーのポート (デフォルト: 3306)

  • MYSQL_USER : データベースのユーザー名

  • MYSQL_PASSWORD : データベースパスワード（オプションですが、安全な接続には推奨されます）

  • MYSQL_DATABASE : デフォルトのデータベース名（オプション）

3. MCP設定に追加

MCP 設定ファイルに次の構成を追加します。

npm 経由でインストールした場合 (オプション 1):

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["mysql-mcp-server"],
      "env": {
        "MYSQL_HOST": "your-mysql-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your-mysql-user",
        "MYSQL_PASSWORD": "your-mysql-password",
        "MYSQL_DATABASE": "your-default-database"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

ソースからビルドした場合 (オプション 2):

{
  "mcpServers": {
    "mysql": {
      "command": "node",
      "args": ["/path/to/mysql-mcp-server/build/index.js"],
      "env": {
        "MYSQL_HOST": "your-mysql-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your-mysql-user",
        "MYSQL_PASSWORD": "your-mysql-password",
        "MYSQL_DATABASE": "your-default-database"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

利用可能なツール

データベース一覧

MySQL サーバー上のアクセス可能なすべてのデータベースを一覧表示します。

パラメータ: なし

例：

{
  "server_name": "mysql",
  "tool_name": "list_databases",
  "arguments": {}
}

リストテーブル

指定されたデータベース内のすべてのテーブルを一覧表示します。

パラメータ:

  • database （オプション）: データベース名（指定されていない場合はデフォルトを使用）

例：

{
  "server_name": "mysql",
  "tool_name": "list_tables",
  "arguments": {
    "database": "my_database"
  }
}

テーブルの説明

特定のテーブルのスキーマを表示します。

パラメータ:

  • database （オプション）: データベース名（指定されていない場合はデフォルトを使用）

  • table （必須）: テーブル名

例：

{
  "server_name": "mysql",
  "tool_name": "describe_table",
  "arguments": {
    "database": "my_database",
    "table": "my_table"
  }
}

クエリ実行

読み取り専用の SQL クエリを実行します。

パラメータ:

  • query （必須）: SQL クエリ（SELECT、SHOW、DESCRIBE、および EXPLAIN ステートメントのみが許可されます）

  • database （オプション）: データベース名（指定されていない場合はデフォルトを使用）

例：

{
  "server_name": "mysql",
  "tool_name": "execute_query",
  "arguments": {
    "database": "my_database",
    "query": "SELECT * FROM my_table LIMIT 10"
  }
}

高度な接続プール構成

MySQL 接続プールの動作をさらに制御するには、追加のパラメータを設定できます。

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["mysql-mcp-server"],
      "env": {
        "MYSQL_HOST": "your-mysql-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "your-mysql-user",
        "MYSQL_PASSWORD": "your-mysql-password",
        "MYSQL_DATABASE": "your-default-database",
        
        "MYSQL_CONNECTION_LIMIT": "10",
        "MYSQL_QUEUE_LIMIT": "0",
        "MYSQL_CONNECT_TIMEOUT": "10000",
        "MYSQL_IDLE_TIMEOUT": "60000",
        "MYSQL_MAX_IDLE": "10"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

これらの詳細オプションを使用すると、次のことが可能になります。

  • MYSQL_CONNECTION_LIMIT : プール内の接続の最大数を制御します（デフォルト: 10）

  • MYSQL_QUEUE_LIMIT : キューに入れる接続リクエストの最大数を設定する（デフォルト: 0、無制限）

  • MYSQL_CONNECT_TIMEOUT : 接続タイムアウトをミリ秒単位で調整します（デフォルト: 10000）

  • MYSQL_IDLE_TIMEOUT : 接続が解放されるまでのアイドル時間を設定します（ミリ秒単位）

  • MYSQL_MAX_IDLE : プールに保持するアイドル接続の最大数を設定します。

テスト

サーバーには、MySQL セットアップの機能を検証するためのテスト スクリプトが含まれています。

1. テストデータベースのセットアップ

このスクリプトは、テスト データベース、テーブル、およびサンプル データを作成します。

# Set your MySQL credentials as environment variables
export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=your_username
export MYSQL_PASSWORD=your_password

# Run the setup script
npm run test:setup

2. MCPツールのテスト

このスクリプトは、テスト データベースに対して各 MCP ツールをテストします。

# Set your MySQL credentials as environment variables
export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=your_username
export MYSQL_PASSWORD=your_password
export MYSQL_DATABASE=mcp_test_db

# Run the tools test script
npm run test:tools

3. すべてのテストを実行する

セットアップ テストとツール テストの両方を実行するには:

# Set your MySQL credentials as environment variables
export MYSQL_HOST=localhost
export MYSQL_PORT=3306
export MYSQL_USER=your_username
export MYSQL_PASSWORD=your_password

# Run all tests
npm test

トラブルシューティング

問題が発生した場合:

  1. サーバーログでエラーメッセージを確認してください

  2. MySQLの資格情報と接続の詳細を確認する

  3. MySQLユーザーに適切な権限があることを確認する

  4. クエリが読み取り専用であり、適切にフォーマットされていることを確認してください

ライセンス

このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。

Available Tools

4 tools
describe_tableB

Show the schema for a specific table

ParametersJSON Schema
NameRequiredDescriptionDefault
tableYesTable name
databaseNoDatabase name (optional, uses default if not specified)

TDQS

B3.4/5.0
Behavior2/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 only states 'show the schema' without disclosing behavioral traits like read-only nature, required permissions, idempotency, or error handling. This is insufficient for a tool with zero annotation coverage.

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 sentence with no waste. However, it could include a brief note on sibling differentiation or usage context, but overall it is appropriately concise.

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?

For a simple introspection tool with two parameters and no output schema, the description is adequate but lacks details on return format, error cases, or prerequisites (e.g., table must exist). It does not reference siblings, leaving the agent to infer context.

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 the baseline is 3. The description adds no additional meaning beyond the schema (e.g., clarifying what 'table' or 'database' refer to). It does not enhance parameter semantics.

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?

"Show the schema for a specific table" uses a specific verb and resource, and clearly distinguishes from siblings like list_tables and execute_query.

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 usage for schema retrieval, but provides no explicit guidance on when to use this tool vs alternatives like list_tables (which only lists names) or execute_query (for custom queries). No when-not-to-use or alternative mentions.

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

execute_queryB

Execute a read-only SQL query

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSQL query (only SELECT, SHOW, DESCRIBE, and EXPLAIN statements are allowed)
databaseNoDatabase name (optional, uses default if not specified)

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 burden. It declares read-only, which is a key behavioral trait, but does not disclose result format, performance, or error handling. The parameter schema already specifies allowed statements, so description adds little beyond that.

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 of 5 words with no redundancy. Front-loaded and efficient.

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 does not explain the return format of the executed query. It also omits potential side effects (though read-only) and error scenarios. For a query tool, this is somewhat acceptable but could be more complete.

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 clear descriptions for both parameters. The tool description adds no additional parameter information beyond what the schema provides. Baseline 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 verb 'Execute' and the resource 'read-only SQL query', distinguishing it from sibling tools like describe_table which describe schema. The title is null but description suffices.

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 explicit guidance on when to use this tool over alternatives. It does not mention that for table metadata users should use describe_table or list_tables. The description is standalone without context.

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

list_databasesA

List all accessible databases on the MySQL server

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

The description indicates it returns 'all accessible databases', which is a basic behavioral trait. No annotations are provided, so the disclosure is minimal but adequate for a simple read operation. It does not mention permissions, system databases, or performance implications.

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?

A single sentence of 9 words front-loaded with the core purpose. No extraneous information, 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?

Given no parameters, no output schema, and no annotations, the description covers the essential purpose. It could be enhanced by clarifying 'accessible' (user privileges) or whether system databases are included, but it is sufficient for a basic list operation.

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 the description need not add parameter details beyond what the schema provides. Per guidelines, baseline is 4 for 0 parameters.

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 'List' and resource 'databases', specifying scope 'all accessible' and context 'MySQL server'. It effectively differentiates from sibling tools like list_tables and describe_table.

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?

The description does not provide any guidance on when to use this tool versus alternatives. No mention of prerequisites, when-not, or references to sibling tools.

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

list_tablesC

List all tables in a specified database

ParametersJSON Schema
NameRequiredDescriptionDefault
databaseNoDatabase name (optional, uses default if not specified)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It only states the basic function but does not elaborate on side effects, read-only nature, error handling (e.g., what if the database doesn't exist), or the meaning of 'default' database. This lack of detail limits transparency.

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 with no redundant information. It is concise and to the point, using no filler 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 optional parameter, no output schema), the description is minimally adequate. However, it misses details like what 'default' database refers to or whether the tool requires any privileges. It does not fully prepare the agent for all usage scenarios.

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

Parameters2/5

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

Schema description coverage is 100% for the single parameter 'database', which already explains its optionality and default behavior. The description adds no additional semantic value beyond restating 'in a specified database', which is already implicit from the schema.

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 'List all tables in a specified database' clearly identifies the action (list) and resource (tables), distinguishing it from sibling tools like list_databases (lists databases) and describe_table (describes a single table). However, the word 'specified' implies the database parameter is required, while the schema marks it as optional, causing minor ambiguity.

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?

The description provides no guidance on when to use this tool versus alternatives such as describe_table or execute_query. There is no mention of prerequisites, limitations, or explicit when-to-use/when-not-to-use instructions, leaving the agent to infer appropriate usage.

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.

  1. 4 tool updatesv0.1.3
    • Addeddescribe_table
    • Addedexecute_query
    • Addedlist_databases
    • Addedlist_tables
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a distinct purpose: listing databases, listing tables, describing a table schema, and executing read-only queries. No overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (describe_table, execute_query, list_databases, list_tables), making them predictable.

Tool Count4/5

Four tools for a read-only database access server is appropriate. It covers the essential introspection and querying needs without being too sparse or excessive.

Completeness4/5

The tool surface covers listing databases, tables, describing schemas, and executing queries—complete for read-only access. Minor gaps like viewing current database or query metadata are acceptable.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • mysql-mcp

    rlembo06
    A
    license
    Not graded
    quality
    D
    maintenance
    A lightweight MCP server providing safe, read-only access to MySQL databases. It enables users to query multiple MySQL instances securely while preventing write operations.
    1,289 npm
    MIT

  • mysql-mcp-server

    mukul975
    A
    license
    Not graded
    quality
    D
    maintenance
    A production-ready MCP server for MySQL database operations, providing secure HTTP endpoints for read-only queries, performance analysis, and server monitoring.
    185 npm
    18
    MIT

  • MySQL Ops MCP

    lemonq3q
    F
    license
    Not graded
    quality
    D
    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
    -

  • mysql-mcp-server-all

    ByteTora
    A
    license
    A
    quality
    C
    maintenance
    A read-only MySQL MCP server supporting stdio, SSE, and Streamable HTTP transports, enabling secure querying and schema inspection of MySQL databases from MCP clients.
    3
    MIT

Appeared in Searches