Click on "Install 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).
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 |
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 |
|
| 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 --help# 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.
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
├── 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. Dates show when Glama detected each change.
v1.0.0create_databaseexecute_sqlget_table_schemaget_table_schema_with_relationslist_databaseslist_tablesEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheNesdark/MariaDB-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
