What can you do with this server?

This server provides a MySQL MCP interface enabling models to query, inspect, and modify databases via tools. * Health & metadata: Check connection health and MySQL version (health_check), list databases (get_databases), list tables (list_tables), and view table structures (describe_table). * Querying: Fetch table data with optional filters and sorting (fetch_table), count rows (count_rows), and execute raw SQL with default read-only restrictions (execute_query or execute_sql). * Data modifications: Insert rows (insert_row), update rows with conditions (update_rows), and delete rows (delete_rows). * Security controls: Credentials are passed per call, read-only connections block writes, SQL defaults to read-only, and update/delete limits are enforced. * Transports: Supports stdio and Streamable HTTP, with Docker deployment option.

Which integrations are available for this server?

Provides tools for interacting with a MySQL database, enabling listing databases and tables, fetching and counting rows, viewing table structures, inserting/updating/deleting rows, and executing SQL queries.

How do I use mysql-mcp?

1. Click on "Deploy 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., "@mysql-mcp Show me the first 50 rows from the users table" 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.

mysql-mcp

by sundonglai03

Overview Schema Source Related Servers Discussions Admin

Python

Remote

mysql-mcp

一个支持 stdio 和 Streamable HTTP 的 MySQL MCP Server。模型可以通过工具查询表、执行受控 SQL，以及插入、更新和删除数据。

快速开始

cd /path/to/mysql-mcp
uv sync

stdio（桌面 MCP 客户端）

{
  "mcpServers": {
    "mysql-mcp": {
      "command": "/path/to/mysql-mcp/.venv/bin/python",
      "args": ["-m", "mysql_mcp"]
    }
  }
}

使用 .venv/bin/python 的绝对路径；不要在客户端配置中依赖 cwd 或 uv run。

Streamable HTTP

.venv/bin/python -m mysql_mcp.mcp_server \
  --transport streamable-http --host 127.0.0.1 --port 8000 --path /mcp

MCP 地址：http://127.0.0.1:8000/mcp。这是 MCP 协议端点，不是普通网页。可信内网可以使用 HTTP；跨不可信网段时建议设置 MYSQL_MCP_AUTH_TOKEN 或使用 --auth-token。没有证书也可以先用 HTTP + Token，HTTPS 不是运行前提。

Docker

docker compose up -d --build
docker compose logs -f mysql-mcp
docker compose down

镜像名为 sundonglai/mysql-mcp:latest，容器名为 mysql-mcp。宿主机默认地址为 http://127.0.0.1:8002/mcp，容器内仍监听 8000；这样可以与 contracts 和 Office 服务同机运行。健康检查地址为 http://127.0.0.1:8002/health。

服务没有连接档案、remember 或兼容接口。数据库凭据必须由每次工具调用提供，连接关闭后立即丢弃。

Related MCP server: Local MySQL Read-only MCP Server

连接数据库

每次业务调用都直接传入数据库凭据：

list_tables(credentials={
  "host": "db.example.com",
  "user": "reader",
  "password": "...",
  "database": "app"
})

服务只在内存中使用凭据，连接关闭后不会保存密码。

工具

工具	作用
`health_check`	检查连接和 MySQL 版本
`get_databases`	列出数据库
`list_tables`	列出表
`describe_table`	查看表结构
`fetch_table`	查询表数据，支持结构化过滤和排序
`count_rows`	统计行数
`execute_query`	执行单条 SQL，默认只读
`insert_row` / `update_rows` / `delete_rows`	数据变更

安全边界

execute_query 默认只允许 SELECT、SHOW、DESCRIBE、EXPLAIN。
永远拒绝多语句 SQL；表名、字段名经过标识符校验，值使用参数绑定。
查询默认返回 50 行，服务端上限 500 行。
结构化更新和删除默认最多影响 1000 行，硬上限 10000 行。
read_only=true 的连接拒绝写操作。
execute_query(read_only=false) 仍是高权限通道，真正的权限控制应使用 MySQL 账号权限。
Docker 默认只绑定回环地址。可信内网开放端口时至少设置 Token；跨不可信网络再增加 HTTPS。

项目结构

src/mysql_mcp/
├── mcp_server.py   # MCP transport 入口
├── server.py       # 工具和 SQL 策略
├── client.py       # MySQL 连接生命周期
└── credentials.py  # 单次凭据校验和 TLS 配置（无文件读写）

开发

.venv/bin/python -m pytest
.venv/bin/ruff check .
.venv/bin/ruff format --check .
docker compose config

不要提交 .venv/、Docker 数据卷或任何密码文件。

License

MIT

Available Tools

11 tools

count_rowsD

ParametersJSON Schema

Name	Required	Description	Default
`where`	No
`table_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

delete_rowsD

ParametersJSON Schema

Name	Required	Description	Default
`where`	Yes
`table_name`	Yes
`where_params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

describe_tableD

ParametersJSON Schema

Name	Required	Description	Default
`table_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

execute_queryD

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes
`limit`	No
`read_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

execute_sqlD

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes
`limit`	No
`read_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fetch_tableD

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`where`	No
`order_by`	No
`table_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_databasesD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

health_checkD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

insert_rowD

ParametersJSON Schema

Name	Required	Description	Default
`row`	Yes
`table_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

list_tablesD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

update_rowsD

ParametersJSON Schema

Name	Required	Description	Default
`where`	Yes
`updates`	Yes
`table_name`	Yes
`where_params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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.

11 tool updatesv0.1.0Sep 10, 2026
- First observedcount_rows
- First observeddelete_rows
- First observeddescribe_table
- First observedexecute_query
- First observedexecute_sql
- First observedfetch_table
- First observedget_databases
- First observedhealth_check
- First observedinsert_row
- First observedlist_tables
- First observedupdate_rows

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

D1.8/5.0

Scored 2026-09-10 08:43 across 11 tools

Disambiguation2/5

Several tools have unclear boundaries: execute_sql and execute_query appear to do nearly the same thing, and fetch_table may overlap with execute_query for reading data. An agent could easily select the wrong generic tool despite the clear CRUD/schema tools.

Naming Consistency4/5

Most names follow a predictable verb_noun snake_case pattern (list_tables, count_rows, delete_rows). Minor inconsistencies exist, such as insert_row singular vs update_rows/delete_rows pluralched and execute_sql vs execute_query using different nouns for the same conceptual operation.

Tool Count4/5

11 tools is a reasonable size for a database MCP server case. However, execute_sql and execute_query are redundant, so not every tool clearly earns its place.

Completeness4/5

The set covers health, database/table listing, schema inspection, row CRUD, counting, and arbitrary SQL, so core database operations are well covered. Dedicated table lifecycle operations are missing but can be handled through execute_sql, making this a minor gap rather than a fatal one.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
stagenth · 数据工具箱 A
com.stagenth
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Databases Data Platforms File Systems
62
commercebridge A
io.github.IsaiahDupree
Remote MCP connector for eBay, Shopify, Best Buy & Etsy marketplace data via the Commerce API
E-commerce & Retail Search
141
classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2

Related MCP Servers

MySQL MCP Server
Databases Developer Tools
slg1119
F
license
Not graded
quality
D
maintenance
Provides MySQL database integration for AI assistants and other MCP clients, allowing them to list tables, read table data, and execute SQL queries.
Updated a year ago (2025-08-04 21:05 UTC)
-
Local MySQL Read-only MCP
Databases Developer Tools
YaangHailong
F
license
Not graded
quality
C
maintenance
Provides a read-only interface to local MySQL databases via MCP, enabling listing databases, tables, describing schemas, and querying rows with structured filters.
Updated 3 months ago (2026-06-30 09:54 UTC)
-
MySQL MCP Server
Databases Developer Tools
PedroUrday
A
license
Not graded
quality
C
maintenance
Enables executing SQL queries against a MySQL database via MCP, returning results as JSON.
Updated 2 months ago (2026-07-05 18:45 UTC)
1,282,895 npm
MIT
mysql-mcp-server
Databases Developer Tools
bomsan69
F
license
A
quality
B
maintenance
MCP server that lets clients run SQL (select/insert/update/delete) against a MySQL database, with readonly and readwrite modes.
Updated a month ago (2026-08-20 02:14 UTC)
4
-