MariaDB-MCP is an MCP server for MariaDB/MySQL that lets clients inspect databases and run controlled SQL over stdio or HTTP/SSE.
Connect using stdio by default or HTTP/SSE with --http <port>, optionally protected by API key authentication.
List all accessible databases.
List tables in a specified database.
Get a table's column schema, including types, nullable, keys, defaults, and extras.
Get a table's schema including foreign-key relations.
Execute SQL queries (SELECT, SHOW, DESCRIBE) with optional parameters; read-only mode blocks writes and file functions like LOAD_FILE/INTO OUTFILE.
Create a database when write mode is enabled (MCP_READ_ONLY=false).
Enforce query timeout and max row limits, with explicit truncation warnings; metadata tools fail rather than return incomplete listings.
Use database selection aliases (database_name, database, db, schema) and verify the active database before each query.
Support SSL, connection pooling, configurable charset, logging, Docker/Compose, and read-only database user grants.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MariaDB-MCP list tables in database genoma"
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.
Servidor MCP escrito en Node.js / JavaScript para interactuar con bases de datos MariaDB/MySQL.
Transporte stdio compatible con el protocolo MCP (Model Context Protocol).
Transporte HTTP/SSE preparado para extenderse con un bridge web.
Conexión pool usando mysql2/promise con tamaño configurable.
Soporte SSL con CA, certificados cliente y configuración de verificación.
Modo solo lectura (READ_ONLY) que bloquea queries de escritura y funciones de archivo (LOAD_FILE, INTO OUTFILE).
Límites de ejecución: tiempo máximo por consulta (MCP_QUERY_TIMEOUT) y tope de filas devueltas (MCP_MAX_ROWS), con aviso explícito cuando un resultado se recorta.
Autenticación por API key en el transporte HTTP (MCP_API_KEY), con comparación en tiempo constante.
Logging a stderr (compatible con stdio transport) y archivos rotados diariamente con winston.
Docker y Docker Compose listos para usar.
Related MCP server: mysql-mcp-server
Herramienta | Descripción |
| Lista todas las bases de datos accesibles. |
| Lista las tablas de una base de datos. |
| Obtiene columnas, tipos, nullable, keys, defaults y extras. |
| Igual que |
| Ejecuta queries |
| Crea una base de datos (requiere |
Todas las herramientas que trabajan sobre una base de datos aceptan el parámetro
database_name y sus alias database, db y schema (útil para clientes que
renombran el parámetro). La conexión se cambia explícitamente con changeUser() y
se verifica con SELECT DATABASE() antes de ejecutar la query, de modo que la
consulta siempre corre sobre la base de datos indicada en la herramienta y nunca
sobre la de una llamada anterior.
execute_sql: si no se envía database_name, se usa DB_NAME (la configurada).
El servidor avisa en el log cuando se ejecuta sin base de datos explícita.
El resto de herramientas exigen database_name y devuelven un error claro con los
alias aceptados si falta.
Tiempo máximo por consulta (MCP_QUERY_TIMEOUT, 30 s por defecto): se aplica con
SET SESSION max_statement_time (MariaDB). Si el servidor no lo admite se intenta
max_execution_time (MySQL, en milisegundos y solo para SELECT); si no hay ninguno
disponible, el límite se desactiva y se avisa una sola vez en el log, en lugar de
romper todas las consultas.
Cuando una consulta agota el tiempo, el servidor la cancela y devuelve un error claro
(MCP_QUERY_TIMEOUT=...). La conexión sigue siendo válida y vuelve al pool, así que un
SELECT desbocado no bloquea el servidor ni contamina las llamadas siguientes.
Tope de filas (MCP_MAX_ROWS, 1000 por defecto): lo aplica el propio servidor con
sql_select_limit = MCP_MAX_ROWS + 1, de modo que un resultado gigante no viaja por
la red. Al recortar, execute_sql responde así en lugar de devolver un array:
{
"rows": [ { "n": 0 }, { "n": 1 } ],
"truncated": true,
"row_limit": 1000,
"received_rows": 1001,
"message": "Resultado truncado a las primeras 1000 filas (límite MCP_MAX_ROWS)..."
} Si el resultado cabe en el tope, la respuesta sigue siendo el array de filas de
siempre (no hay cambio de forma). Con MCP_MAX_ROWS=0 el tope se desactiva.
Las herramientas de metadatos (list_databases, list_tables, get_table_schema,
get_table_schema_with_relations) fallan con un error claro si el tope recorta su
resultado, en lugar de devolver un listado incompleto: es peor concluir que una tabla
no existe que recibir el aviso de subir MCP_MAX_ROWS.
Los límites se reaplican tras cada cambio de base de datos, porque COM_CHANGE_USER
devuelve las variables de sesión a su valor por defecto.
Node.js >= 18 (recomendado 20 LTS)
MariaDB/MySQL accesible desde la red del servidor
# Clonar o copiar la carpeta MariaDB-MCP
cd MariaDB-MCP
# Instalar dependencias
npm installCopia el archivo de ejemplo y ajusta tus credenciales:
cp .env.example .envVariables disponibles:
Variable | Descripción | Default |
| Host del servidor MariaDB |
|
| Puerto |
|
| Usuario |
|
| Contraseña | (vacío) |
| Base de datos por defecto |
|
| Charset de conexión |
|
| Habilitar SSL |
|
| Ruta al certificado CA | (vacío) |
| Ruta al certificado cliente | (vacío) |
| Ruta a la clave privada cliente | (vacío) |
| Verificar certificado |
|
| Verificar identidad del host |
|
| Modo solo lectura |
|
| Tamaño máximo del pool |
|
| Segundos máximos por consulta ( |
|
| Filas máximas devueltas por herramienta ( |
|
| API key(s) exigida(s) en el transporte HTTP, separadas por coma | (vacío = sin auth) |
|
| exigir si hay clave |
| Nivel de log ( |
|
| Orígenes CORS separados por coma | (vacío) |
| Hosts permitidos separados por coma |
|
npm start
# o
node src/index.jsnode src/index.js --http 3000node src/index.js --helpDefine una o varias claves en .env para proteger el endpoint MCP:
MCP_API_KEY=mi-clave-secreta
# o varias: MCP_API_KEY=clave-1,clave-2Con la clave definida, todas las rutas salvo /health devuelven 401 si no
se envía. El cliente debe incluir una de estas cabeceras:
Authorization: Bearer mi-clave-secreta
X-API-Key: mi-clave-secreta# Verificar
$ curl -i -X POST http://localhost:3005/mcp -H 'Authorization: Bearer mi-clave-secreta'
HTTP/1.1 401 Unauthorized # sin clave
HTTP/1.1 200 OK # con clave correcta
$ curl -i http://localhost:3005/health # sigue sin clave para el healthcheck
# → {"status":"healthy"} (sin credenciales: solo el estado)/health nunca exige credenciales, para no romper el healthcheck de Docker y de los
orquestadores. Cuando hay autenticación configurada solo responde { status }; el
detalle (server, version, database, readOnly, pool) requiere la misma clave que
/mcp, igual que el mensaje de error cuando la base de datos no responde.
Variables relacionadas:
Variable | Descripción |
| Claves válidas separadas por coma. Vacío → autenticación deshabilitada (se avisa en el log). |
|
|
La comparación de claves se hace en tiempo constante (hash SHA-256 +
timingSafeEqual). La comparación no se registra en los logs.
# Modo stdio ( foreground )
docker-compose run --rm mcp-server
# Modo HTTP ( background )
docker-compose up -d mcp-serverAsegúrese de que las variables de entorno estén definidas en un archivo
.envo en el shell antes de ejecutardocker-compose.
MULTI_STATEMENTS y LOCAL_INFILE están desactivados en el pool de conexiones.
En modo READ_ONLY, solo se permiten queries que inicien con SELECT, SHOW, DESC, DESCRIBE o USE.
Se bloquean explícitamente las funciones LOAD_FILE() y sentencias INTO OUTFILE/DUMPFILE.
Se detecta y se alerta si el usuario de base de datos posee el privilegio global FILE.
Límites de ejecución por sesión (tiempo máximo de consulta y tope de filas), que además acotan el consumo de memoria del servidor y el tamaño de las respuestas.
Autenticación API key opcional en el transporte HTTP (MCP_API_KEY), con
comparación en tiempo constante; /health queda abierto para el healthcheck, pero
solo devuelve { status } cuando hay autenticación configurada.
Solo lectura real con grants: MCP_READ_ONLY filtra por prefijo de sentencia y es
una comodidad, no una frontera de seguridad (un CTE con UPDATE, una función
almacenada o una sentencia preparada se le escapan). La garantía la da el usuario de
base de datos, y al arrancar se avisa si ese usuario tiene privilegios de escritura.
Ejemplo listo para ejecutar en examples/mariadb-readonly-user.sql:
CREATE USER IF NOT EXISTS 'mcp_ro'@'%' IDENTIFIED BY '...';
GRANT SELECT, SHOW VIEW ON `genoma`.* TO 'mcp_ro'@'%';y en .env: DB_USER=mcp_ro con su DB_PASSWORD.
Cada ejecución verifica con SELECT DATABASE() que corre sobre la base de datos
solicitada; si no coincide, la conexión se descarta y se devuelve un error en vez
de resultados de otra base de datos.
MariaDB-MCP/
├── src/
│ ├── index.js # Punto de entrada y CLI
│ ├── server.js # Lógica MCP, pool y herramientas
│ ├── config.js # Variables de entorno
│ └── logger.js # Configuración de winston
├── test/ # Pruebas (node --test)
├── examples/ # Ejemplos, p. ej. usuario MariaDB de solo lectura
├── logs/ # Archivos de log rotados
├── .env.example
├── .gitignore
├── .dockerignore
├── Dockerfile
├── docker-compose.yml
├── package.json
└── README.mdMIT
Crea una nueva base de datos si no existe. Requiere modo escritura (READ_ONLY=false).
| Name | Required | Description | Default |
|---|---|---|---|
| database_name | Yes | Nombre de la base de datos a crear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses idempotency ('si no existe') and the write mode requirement. However, it omits details such as return value, error behavior if creation fails, or potential side effects. Minimal but adequate for a simple creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and condition. No wasted words. Every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description lacks details on return value or error states. Without an output schema, the agent is left to infer behavior. This gap reduces completeness from a perfect score, but the core usage is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the description adds no extra semantics beyond the schema's 'Nombre de la base de datos a crear'. Following the baseline, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Crea una nueva base de datos' (Creates a new database). The tool name aligns with the action, and the condition 'si no existe' distinguishes it from listing tools and SQL execution. Sibling tools are unrelated, so this tool's purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the prerequisite 'Requiere modo escritura (READ_ONLY=false)' and the condition 'si no existe', indicating when to use (when database does not exist) and requirement. However, it does not explicitly recommend when to use this over alternatives like execute_sql for database creation, but the condition provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ejecuta una consulta SQL (SELECT, SHOW, DESCRIBE) y retorna los resultados. En modo solo lectura (por defecto), se bloquean queries de escritura.
| Name | Required | Description | Default |
|---|---|---|---|
| sql_query | Yes | Consulta SQL a ejecutar | |
| parameters | No | Parámetros para consultas parametrizadas (reemplazan ?) | |
| database_name | Yes | Base de datos sobre la cual ejecutar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It discloses the read-only mode blocking writes, but lacks details on authentication, rate limits, or query execution constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The purpose is front-loaded, and each sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain the return format or result structure. For a tool that returns query results, this leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate descriptions. The tool description adds no extra meaning beyond what the schema already provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes SQL queries (SELECT, SHOW, DESCRIBE) and returns results, distinguishing it from sibling tools that manage databases or schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies read-only mode by default and that writes are blocked, providing clear usage context. However, it does not explicitly mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene la estructura de columnas de una tabla (nombre, tipo, nullable, clave, default, extra).
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Nombre de la tabla | |
| database_name | Yes | Nombre de la base de datos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. 'Obtiene' implies a read-only operation, but no permissions, rate limits, or performance characteristics are mentioned. The tool likely returns the schema list, but the description does not disclose any behavioral traits 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently states the tool's purpose and output. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the returned fields, which partially compensates for the lack of an output schema. However, given the existence of a sibling tool for schema with relations, the description should clarify that this tool returns basic schema only. Also, no context on error conditions or usage examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds meaning by listing the returned fields (name, type, nullable, key, default, extra), which goes beyond the schema. However, it does not explain parameter formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves column structure (type, nullable, key, default, extra) of a table. It uses a specific verb ('obtiene' - gets) and resource ('estructura de columnas de una tabla'). However, it does not differentiate from the sibling tool 'get_table_schema_with_relations', which might imply more detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need column metadata. It provides no explicit guidance on when not to use this tool or mention of alternatives like 'get_table_schema_with_relations'. Given the sibling, some clarification would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene la estructura de columnas incluyendo relaciones de clave foránea.
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Nombre de la tabla | |
| database_name | Yes | Nombre de la base de datos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the basic functionality without mentioning read-only nature, error conditions, performance implications, or any side effects. For a tool with no annotations, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 and key differentiator. There is no superfluous content, and the structure is front-loaded with the verb, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential information (gets column structure with FK relations) but omits details about output format, ordering, or potential limitations. Given the tool's simplicity, it is adequate but could be more fleshed out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already described clearly in the schema. The description adds no additional semantic nuance beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states verb 'obtiene' (gets) and resource 'estructura de columnas incluyendo relaciones de clave foránea' (column structure including foreign key relationships). This clearly differentiates the tool from sibling get_table_schema, which likely returns only column structure without relations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_table_schema. There is no mention of prerequisites or exclusions, leaving the AI agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista todas las bases de datos accesibles en el servidor MariaDB.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only states the tool lists accessible databases. It does not disclose potential behavioral traits like performance, authentication requirements, or limitations, but for a simple read-only listing, it is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete and sufficient for an agent to understand its function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description adds meaning beyond the empty schema by confirming the action and scope (listing all accessible databases).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all accessible databases on a MariaDB server, using a specific verb and resource. It effectively distinguishes from sibling tools like create_database and list_tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no when-to-use or when-not-to-use scenarios mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista todas las tablas de una base de datos específica.
| Name | Required | Description | Default |
|---|---|---|---|
| database_name | Yes | Nombre de la base de datos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states the action without disclosing behavioral traits such as whether it is read-only, required permissions, or output format. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. However, it is slightly under-informative; a bit more detail would improve it without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description minimally covers the tool's purpose. Missing details like what information is returned (e.g., table names only). For a list tool, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (database_name described in schema). The description adds no extra context beyond what the schema provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Verb 'Lista' (list) and resource 'tablas de una base de datos específica' (tables of a specific database) clearly state what the tool does. It effectively distinguishes from siblings like list_databases (lists databases) and get_table_schema (schema details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With siblings like list_databases and execute_sql, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_databaseexecute_sqlget_table_schemaget_table_schema_with_relationslist_databaseslist_tablesScored across 6 tools
Each tool has a clear, non-overlapping purpose: database creation, SQL execution, schema retrieval (with optional relations), and listing databases/tables. The two schema tools are differentiated by the inclusion of foreign key relations.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_database, list_databases, get_table_schema). The style is uniform and predictable.
Six tools cover essential database operations—listing, schema inspection, SQL execution, and database creation—without being excessive or sparse for the server's scope.
The set covers read operations well but lacks explicit tools for dropping databases or altering tables. The execute_sql tool can perform write operations if mode allows, but dedicated tools for update/delete are missing, leaving notable gaps.
PostgreSQL, MySQL, and SQL Server in one session. 26 read-only MCP tools for AI agents.
Text-to-SQL MCP server: read-only queries on PostgreSQL, MySQL and SQL Server with your real schema
Guard AI agents' PostgreSQL/MySQL access via MCP: SQL audit, auth, masking, write approval
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.