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에서 설치

지엑스피1

소스에서 빌드

# 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 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

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