Skip to main content
Glama
enesjakozh
dpflucas

MySQL Database Access

by dpflucas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

versión npm insignia de herrería

Servidor MCP de acceso a bases de datos MySQL

Este servidor MCP proporciona acceso de solo lectura a bases de datos MySQL. Permite:

  • Lista de bases de datos disponibles

  • Listar tablas en una base de datos

  • Describir esquemas de tablas

  • Ejecutar consultas SQL de solo lectura

Características de seguridad

  • Acceso de solo lectura : solo se permiten las instrucciones SELECT, SHOW, DESCRIBE y EXPLAIN

  • Validación de consultas : evita la inyección de SQL y bloquea cualquier intento de modificación de datos

  • Tiempo de espera de consulta : evita que las consultas de larga duración consuman recursos

  • Límite de filas : evita la devolución excesiva de datos

Related MCP server: mysql-mcp-server

Instalación

1. Instale utilizando uno de estos métodos:

Instalar desde NPM

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

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

Construir desde la fuente

# 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

Instalar a través de Smithery

Para instalar MySQL Database Access MCP Server para Claude AI automáticamente a través de Smithery :

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

2. Configurar variables de entorno

El servidor requiere las siguientes variables de entorno:

  • MYSQL_HOST : Nombre de host del servidor de base de datos

  • MYSQL_PORT : Puerto del servidor de base de datos (predeterminado: 3306)

  • MYSQL_USER : Nombre de usuario de la base de datos

  • MYSQL_PASSWORD : Contraseña de la base de datos (opcional, pero recomendada para conexiones seguras)

  • MYSQL_DATABASE : Nombre de la base de datos predeterminada (opcional)

3. Agregar a la configuración de MCP

Agregue la siguiente configuración a su archivo de configuración de MCP:

Si lo instaló mediante npm (Opción 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": []
    }
  }
}

Si lo construyó desde la fuente (Opción 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": []
    }
  }
}

Herramientas disponibles

lista_de_bases_de_datos

Enumera todas las bases de datos accesibles en el servidor MySQL.

Parámetros : Ninguno

Ejemplo :

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

listas_de_tablas

Enumera todas las tablas de una base de datos especificada.

Parámetros :

  • database (opcional): nombre de la base de datos (usa el predeterminado si no se especifica)

Ejemplo :

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

describe_tabla

Muestra el esquema de una tabla específica.

Parámetros :

  • database (opcional): nombre de la base de datos (usa el predeterminado si no se especifica)

  • table (obligatorio): Nombre de la tabla

Ejemplo :

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

ejecutar_consulta

Ejecuta una consulta SQL de solo lectura.

Parámetros :

  • query (obligatoria): consulta SQL (solo se permiten las sentencias SELECT, SHOW, DESCRIBE y EXPLAIN)

  • database (opcional): nombre de la base de datos (usa el predeterminado si no se especifica)

Ejemplo :

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

Configuración avanzada del grupo de conexiones

Para obtener más control sobre el comportamiento del grupo de conexiones MySQL, puede configurar parámetros adicionales:

{
  "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": []
    }
  }
}

Estas opciones avanzadas le permiten:

  • MYSQL_CONNECTION_LIMIT : controla el número máximo de conexiones en el grupo (valor predeterminado: 10)

  • MYSQL_QUEUE_LIMIT : Establece el número máximo de solicitudes de conexión para poner en cola (valor predeterminado: 0, ilimitado)

  • MYSQL_CONNECT_TIMEOUT : ajusta el tiempo de espera de la conexión en milisegundos (valor predeterminado: 10000)

  • MYSQL_IDLE_TIMEOUT : configura cuánto tiempo puede estar inactiva una conexión antes de liberarse (en milisegundos)

  • MYSQL_MAX_IDLE : Establece el número máximo de conexiones inactivas que se mantendrán en el grupo

Pruebas

El servidor incluye scripts de prueba para verificar la funcionalidad con su configuración de MySQL:

1. Configurar la base de datos de prueba

Este script crea una base de datos de prueba, una tabla y datos de muestra:

# 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. Probar las herramientas MCP

Este script prueba cada una de las herramientas MCP contra la base de datos de prueba:

# 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. Ejecutar todas las pruebas

Para ejecutar pruebas de configuración y de herramientas:

# 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

Solución de problemas

Si encuentra problemas:

  1. Verifique los registros del servidor para ver si hay mensajes de error

  2. Verifique sus credenciales de MySQL y los detalles de conexión

  3. Asegúrese de que su usuario MySQL tenga los permisos adecuados

  4. Compruebe que su consulta sea de solo lectura y tenga el formato correcto

Licencia

Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.

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