de en es ja ko ru zh

MariaDB MCP Server

Name: MariaDB MCP Server
Author: bretoreta

by bretoreta

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

MariaDB / MySQL 데이터베이스 액세스 MCP 서버

이 MCP 서버는 MariaDB/MySQL 데이터베이스에 대한 액세스를 제공합니다.

이를 통해 다음이 가능합니다.

사용 가능한 데이터베이스 나열
데이터베이스의 테이블 나열
테이블 스키마 설명
SQL 쿼리 실행

보안 기능

읽기 전용 액세스 기본값 : SELECT, SHOW, DESCRIBE 및 EXPLAIN
쿼리 검증 : SQL 주입을 방지하고 모든 데이터 수정 시도를 차단합니다.
쿼리 시간 초과 : 장기 실행 쿼리가 리소스를 소모하는 것을 방지합니다.
행 제한 : 과도한 데이터 반환을 방지합니다.

Related MCP server: MySQL MCP Server

설치

옵션 1: 소스에서 빌드

지엑스피1

2. 환경 변수 구성

서버에는 다음과 같은 환경 변수가 필요합니다.

MARIADB_HOST: 데이터베이스 서버 호스트 이름
MARIADB_PORT: 데이터베이스 서버 포트(기본값: 3306)
MARIADB_USER: 데이터베이스 사용자 이름
MARIADB_PASSWORD: 데이터베이스 비밀번호
MARIADB_DATABASE: 기본 데이터베이스 이름(선택 사항)
MARIADB_ALLOW_INSERT: 거짓
MARIADB_ALLOW_UPDATE: 거짓
MARIADB_ALLOW_DELETE: 거짓
MARIADB_TIMEOUT_MS: 10000
MARIADB_ROW_LIMIT: 1000

3. MCP 설정에 추가

MCP 설정 파일에 다음 구성을 추가하세요.

소스에서 빌드한 경우:

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

사용 가능한 도구

목록_데이터베이스

MariaDB/MySQL 서버에서 접근 가능한 모든 데이터베이스를 나열합니다. 매개변수 : 없음

예 :

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

리스트_테이블

지정된 데이터베이스의 모든 테이블을 나열합니다.

매개변수 :

database (선택 사항): 데이터베이스 이름(지정하지 않으면 기본값 사용)

예 :

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

설명_테이블

특정 테이블에 대한 스키마를 보여줍니다.

매개변수 :

database (선택 사항): 데이터베이스 이름(지정하지 않으면 기본값 사용)
table (필수): 테이블 이름

예 :

{
  "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"
  }
}

실행_쿼리

SQL 쿼리를 실행합니다.

매개변수 :

query (필수): SQL 쿼리
database (선택 사항): 데이터베이스 이름(지정하지 않으면 기본값 사용)

예 :

{
  "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"
  }
}

테스트

서버는 사용자의 MariaDB 설정으로 기능을 검증하기 위해 자동으로 MariaDB를 테스트합니다.

문제 해결

문제가 발생하는 경우:

오류 메시지는 서버 로그에서 확인하세요.
MariaDB 자격 증명 및 연결 세부 정보를 확인하세요.
MariaDB 사용자에게 적절한 권한이 있는지 확인하세요.
귀하의 쿼리가 읽기 전용이고 올바르게 형식화되었는지 확인하십시오.

영감 https://github.com/rjsalgado/mariadb-mcp-server

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

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.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_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 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.

4 tool updatesAug 15, 2025
- First observeddescribe_table
- First observedexecute_query
- First observedlist_databases
- First observedlist_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

B3.4/5.0

Scored 2026-04-18 10:10 across 4 tools

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

Related MCP Connectors

QueryBearOAuth
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
AI2SQLOAuth
io.ai2sql
Generate, fix, explain and run read-only SQL on PostgreSQL, MySQL and SQL Server
Databases Developer Tools
1
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
mcpmyadminOAuth
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 8 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
37 npm
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
9 npm
MIT