Which integrations are available for this server?

Provides access to MariaDB databases, allowing users to list databases, explore table schemas, and execute read-only SQL queries with security features like query validation and resource limits. Enables interaction with MySQL databases through capabilities to list available databases, browse tables, describe table structures, and run SQL queries with built-in security controls.

How do I use MariaDB MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MariaDB MCP Server show me the tables in the sales database" 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.

de en es ja ko ru zh

MariaDB MCP Server

by bretoreta

Overview Schema Related Servers Score Discussions

JavaScript

Remote

MariaDB / MySQL Database Access MCP Server

This MCP server provides access to MariaDB / MySQL databases.

It allows you to:

List available databases
List tables in a database
Describe table schemas
Execute SQL queries

Security Features

Read-only access Default: SELECT, SHOW, DESCRIBE, and EXPLAIN
Query validation: Prevents SQL injection and blocks any data modification attempts
Query timeout: Prevents long-running queries from consuming resources
Row limit: Prevents excessive data return

Related MCP server: MySQL MCP Server

Installation

Option 1: Build from Source

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

# Install dependencies and build
pnpm install
pnpm run build

2. Configure environment variables

The server requires the following environment variables:

MARIADB_HOST: Database server hostname
MARIADB_PORT: Database server port (default: 3306)
MARIADB_USER: Database username
MARIADB_PASSWORD: Database password
MARIADB_DATABASE: Default database name (optional)
MARIADB_ALLOW_INSERT: false
MARIADB_ALLOW_UPDATE: false
MARIADB_ALLOW_DELETE: false
MARIADB_TIMEOUT_MS: 10000
MARIADB_ROW_LIMIT: 1000

3. Add to MCP settings

Add the following configuration to your MCP settings file:

If you built from source:

{
  "mcpServers": {
    "mariadb": {
      "command": "node",
      "args": ["/path/to/mariadb-mcp-server/dist/index.js"],
      "env": {
        "MARIADB_HOST": "your-host",
        "MARIADB_PORT": "3306",
        "MARIADB_USER": "your-user",
        "MARIADB_PASSWORD": "your-password",
        "MARIADB_DATABASE": "your-default-database",
        "MARIADB_ALLOW_INSERT": "false",
        "MARIADB_ALLOW_UPDATE": "false",
        "MARIADB_ALLOW_DELETE": "false",
        "MARIADB_TIMEOUT_MS": "10000",
        "MARIADB_ROW_LIMIT": "1000",
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Available Tools

list_databases

Lists all accessible databases on the MariaDB / MySQL server. Parameters: None

Example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "sessionId": "session_id from /sse call",
    "name": "list_databases"
  }
}

list_tables

Lists all tables in a specified database.

Parameters:

database (optional): Database name (uses default if not specified)

Example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "sessionId": "session_id from /sse call",
    "name": "list_tables",
    "database": "my_database_name"
  }
}

describe_table

Shows the schema for a specific table.

Parameters:

database (optional): Database name (uses default if not specified)
table (required): Table name

Example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "sessionId": "session_id from /sse call",
    "name": "describe_table",
    "database": "my_database_name",
    "table": "my_table_name"
  }
}

execute_query

Executes a SQL query.

Parameters:

query (required): SQL query
database (optional): Database name (uses default if not specified)

Example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "sessionId": "session_id from /sse call",
    "name": "execute_query",
    "query": "SELECT * FROM my_table LIMIT 10"
  }
}

Testing

The server automatically tests MariaDB to verify functionality with your MariaDB setup:

Troubleshooting

If you encounter issues:

Check the server logs for error messages
Verify your MariaDB credentials and connection details
Ensure your MariaDB user has appropriate permissions
Check that your query is read-only and properly formatted

Inspiration https://github.com/rjsalgado/mariadb-mcp-server

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

4 tools

describe_tableB

Show the schema for a specific table

ParametersJSON Schema

Name	Required	Description	Default
`database`	No	Database name (optional, uses default if not specified)
`table`	Yes	Table name

TDQS

B3.3/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 the full burden of behavioral disclosure. It states the tool shows schema information but lacks details on permissions needed, response format, error handling, or whether it's a read-only operation. This is inadequate for a tool with no 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with zero waste—it directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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 low complexity (2 parameters, no output schema) and high schema coverage, the description is minimally adequate. However, it lacks output details and behavioral context, which are important since no annotations or output schema exist to compensate.

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 input schema already documents both parameters ('database' as optional, 'table' as required). The description adds no additional meaning beyond what the schema provides, such as examples or constraints, meeting the baseline for high schema coverage.

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 clearly states the tool's purpose with a specific verb ('show') and resource ('schema for a specific table'), making it easy to understand. It distinguishes from siblings like 'list_tables' (which lists table names) by focusing on schema details, though it doesn't explicitly mention this distinction.

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 when schema information is needed, but provides no explicit guidance on when to use this tool versus alternatives like 'list_tables' or 'execute_query'. No prerequisites, exclusions, or context for tool selection are mentioned.

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

execute_queryC

Execute a SQL query

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL query (only SELECT, SHOW, DESCRIBE, and EXPLAIN statements are allowed)
`database`	No	Database 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 behavioral disclosure. It states the action ('execute a SQL query') but doesn't mention critical behavioral traits such as permissions required, whether it's read-only or mutating, potential side effects, rate limits, or response format. This is a significant gap for a tool that executes queries.

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 extremely concise with a single sentence ('Execute a SQL query'), which is front-loaded and wastes no words. It efficiently communicates the core purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of executing SQL queries, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like safety, permissions, or result format, which are crucial for an agent to use this tool correctly and safely in context with sibling tools.

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?

The description adds no parameter semantics beyond what the input schema provides. Since schema description coverage is 100%, the baseline is 3. The schema already documents the query parameter with allowed SQL statements and the optional database parameter, so the description doesn't compensate or add value here.

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 clearly states the verb ('execute') and resource ('SQL query'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like describe_table or list_tables, which also involve database operations but with different verbs and scopes.

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 guidance is provided on when to use this tool versus alternatives like describe_table or list_databases. The description lacks context about appropriate use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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

list_databasesB

List all accessible databases on the MariaDB server

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/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 behavioral disclosure. It states what the tool does but doesn't mention important traits like whether this is a read-only operation, if it requires specific permissions, potential rate limits, or what the output format looks like. This leaves significant gaps for a tool that interacts with a database server.

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, efficient sentence that directly states the tool's function without any unnecessary words. It's perfectly front-loaded and wastes no space, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that this is a database interaction tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'accessible' means in terms of permissions, doesn't describe the return format (e.g., list of strings, structured objects), and provides no behavioral context beyond the basic action.

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, and the schema description coverage is 100%, so there's no need for parameter documentation in the description. The description appropriately focuses on the tool's purpose without redundant parameter information, earning a high baseline score for this dimension.

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 clearly states the verb ('List') and resource ('all accessible databases on the MariaDB server'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_tables' or 'describe_table', which prevents a perfect score.

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 like 'list_tables' or 'describe_table'. It lacks any context about prerequisites, timing, or exclusions, leaving the agent to infer usage based on tool names alone.

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

Name	Required	Description	Default
`database`	No	Database 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 full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, what permissions are required, whether it returns metadata or just names, if there are rate limits, or what happens when the database doesn't exist.

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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple list operation and front-loads the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the list returns (names only? with metadata?), whether there are pagination considerations, what happens with large databases, or any error conditions. The context signals indicate this is a simple tool, but the description leaves too many behavioral questions unanswered.

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 schema already documents the single parameter fully. The description mentions 'specified database' which aligns with the schema but doesn't add meaningful semantic context beyond what the schema provides, such as explaining what 'default' means or providing examples.

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 clearly states the action ('List all tables') and target resource ('in a specified database'), providing specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_databases' or 'describe_table', which would require a 5.

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 guidance is provided about when to use this tool versus alternatives like 'list_databases' or 'describe_table'. The description mentions a database parameter but doesn't explain when to specify it versus using the default, or when this tool is appropriate versus executing a query.

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. Dates show when Glama detected each change.

4 tool updatesAug 15, 2025
- First observeddescribe_table
- First observedexecute_query
- First observedlist_databases
- First observedlist_tables

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: describe_table shows table schemas, execute_query runs SQL queries, list_databases enumerates databases, and list_tables lists tables within a database. The boundaries are well-defined, preventing agent misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (describe_table, execute_query, list_databases, list_tables) with clear, descriptive verbs. There are no deviations in style or convention, making the set predictable and readable.

Tool Count4/5

Four tools is reasonable for a MariaDB server, covering core operations like listing databases/tables, describing schemas, and executing queries. It feels slightly thin as it lacks CRUD operations (e.g., create_table, insert_data), but it's well-scoped for basic database inspection and query execution.

Completeness3/5

The tools provide good coverage for database inspection and query execution, but there are notable gaps in CRUD operations (e.g., no create_table, update_data, or delete_table). Agents can work around this using execute_query, but the surface is incomplete for full database management workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

QueryBear
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
data
co.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Databases Developer Tools
2
wgong-sqlite-mcp-server
ai.smithery
Explore, query, and inspect SQLite databases with ease. List tables, preview results, and view det…
Databases Developer Tools
21
mcpmyadmin
ai.mcpmyadmin
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Databases Security
2

Related MCP Servers

MariaDB MCP Server
Databases Shell Access
yawlhead91
A
license
A
quality
D
maintenance
Enables interaction with MariaDB databases through secure read-only operations. Supports database exploration, schema inspection, and SQL query execution with comprehensive logging and connection pooling.
Updated 7 months ago (2026-01-21 11:15 UTC)
5
2
MIT
MySQL MCP Server
Databases Developer Tools
jeweis
F
license
Not graded
quality
D
maintenance
Enables safe interaction with MySQL databases through SELECT queries, table structure inspection, and database schema exploration. Provides read-only access to query data and examine database metadata.
Updated a year ago (2025-07-05 08:44 UTC)
1
-
@cano721/mysql-mcp-server
Databases Developer Tools
cano721
A
license
A
quality
D
maintenance
Enables read-only MySQL database access, allowing listing databases, tables, describing schemas, and executing SELECT/SHOW/DESCRIBE/EXPLAIN queries.
Updated 8 months ago (2026-01-09 08:45 UTC)
7
89
4
MIT
mysql-mcp-server
Databases Developer Tools
xujcbiz
A
license
A
quality
D
maintenance
Provides read-only MySQL query execution, database/table browsing, and table structure inspection with SQL safety validation.
Updated 3 months ago (2026-06-10 13:11 UTC)
5
23
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bretoreta/mariadb-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server