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., "@dynamic-db-mcp-server Register instance demo-db on host 192.168.1.100 port 3306"
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 Server. 运行时注册数据库连接, 执行 SQL 时自带破坏性语句拦截.
传统的数据库 MCP Server 要求把所有连接配置事先写进环境变量或配置文件. 这在以下场景不现实:
有几十/上百个数据库实例
实例 IP 经常变动
不想维护一份静态配置文件
需要 AI 动态发现并连接数据库
dynamic-db-mcp-server 翻转了模型: 连接在运行时通过工具调用注册. AI 提供 host/port/user/password, Server 测试连接, 缓存它, 返回 instance_id 供后续查询使用.
Related MCP server: MySQL MCP Server
动态注册 — 无需预配置连接列表, 运行时注册任意 MySQL 兼容数据库
连接复用 — 注册的连接会被缓存, 不重复握手
SQL 安全 — 只读查询 (SELECT/SHOW/WITH/EXPLAIN/DESC) 直接执行; 破坏性语句 (DROP/DELETE/UPDATE/INSERT/ALTER/TRUNCATE) 需显式确认; 危险语句 (OUTFILE/DUMPFILE/LOAD_FILE/SHUTDOWN) 一律拒绝
MySQL 协议兼容 — 适用于 MySQL, MariaDB, TDSQL, TDSQL-C 等任何使用 MySQL 线协议的数据库
配置无敏感数据 — 无硬编码凭据, 所有连接均为运行时提供
无状态 — 连接存在于 MCP 进程内存中, 重启即清空
pip install dynamic-db-mcp-server或通过 uv / uvx 运行:
uvx dynamic-db-mcp-server在你的 MCP 客户端配置中添加 (如 opencode.jsonc, claude_desktop_config.json):
{
"mcpServers": {
"dynamic-db": {
"command": "uvx",
"args": ["dynamic-db-mcp-server"]
}
}
}或从源码运行:
{
"mcpServers": {
"dynamic-db": {
"command": "python",
"args": ["-m", "dynamic_db_mcp_server"]
}
}
}1. register_instance(name="my-db", host="10.0.0.5", port=3306, user="root", password="***")
→ {"instance_id": "my-db", "status": "connected"}
→ 连接已测试并缓存
2. list_instances()
→ [{"instance_id": "my-db", "host": "10.0.0.5", "port": 3306, "user": "root", "status": "connected"}]
3. execute_sql(instance_id="my-db", sql="SELECT 1")
→ {"columns": ["1"], "rows": [[1]], "row_count": 1}
4. execute_sql(instance_id="my-db", sql="DROP TABLE temp_test")
→ {"error": "Destructive operation requires confirmation", "sql_type": "DESTRUCTIVE", "statement": "DROP"}
5. execute_sql(instance_id="my-db", sql="DROP TABLE temp_test", confirm_destructive=true)
→ {"affected_rows": 0}工具 | 说明 |
| 注册数据库连接 (用 |
| 列出所有已注册实例 (不返回密码) |
| 执行 SQL. 只读直接通过, 破坏性需 |
| 列出实例上的所有数据库 |
| 列出指定库的表 (含行数和大小) |
| 查看表结构 (列信息 + |
类别 | 关键字 | 行为 |
只读 | SELECT, SHOW, WITH, EXPLAIN, DESC, DESCRIBE | 直接执行 |
破坏性 | DROP, TRUNCATE, DELETE, UPDATE, INSERT, ALTER, RENAME, GRANT, REVOKE, CREATE | 需 |
危险 | OUTFILE, DUMPFILE, LOAD_FILE, SHUTDOWN, KILL | 一律拒绝 |
AI Agent
│
│ MCP 协议 (stdio)
▼
┌──────────────────────────────────────┐
│ dynamic-db-mcp-server │
│ │
│ FastMCP Server ──→ 6 个工具 │
│ │ │
│ ConnectionManager │
│ - register / get / list │
│ - ping + 自动重连 │
│ - per-instance threading.Lock │
│ │ │
│ SqlValidator │
│ - 关键字分类 │
│ - 只读 / 破坏性 / 危险 │
│ │ │
│ DbExecutor (pymysql) │
│ - execute / list / schema │
└──────────────────────────────────────┘
│
│ TCP 3306
▼
MySQL / MariaDB / TDSQL / TDSQL-CMIT
Execute a SQL statement on a registered instance.
SQL is classified before execution:
Read-only (SELECT/SHOW/WITH/EXPLAIN/DESC): executes directly.
Destructive (DROP/DELETE/UPDATE/INSERT/ALTER/TRUNCATE/CREATE/...): requires confirm_destructive=true.
Blocked (OUTFILE/DUMPFILE/LOAD_FILE/SHUTDOWN/KILL): always rejected.
Args: instance_id: The instance name from register_instance. sql: The SQL statement to execute. database: Optional database to switch to before executing. confirm_destructive: Set to true to allow destructive operations.
Returns: JSON string with query results (columns/rows/row_count) or affected_rows for DML, or error/safety rejection details.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| database | No | ||
| instance_id | Yes | ||
| confirm_destructive | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Thoroughly describes SQL classification, execution rules, and return values. No annotations provided, so description carries full burden and succeeds.
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?
Well-structured with bullet points and clear sections. Some redundancy could be trimmed but overall efficient and front-loaded.
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?
Covers execution behavior, parameter roles, return types (JSON with columns/rows/affected_rows). With output schema existing, description is sufficiently complete.
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?
Despite 0% schema coverage, description explains all four parameters: instance_id, sql, database (optional), confirm_destructive. Adds value beyond schema structure.
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?
Clearly states tool executes a SQL statement on a registered instance, differentiating from read-only sibling tools. Lists specific operations and behavior.
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?
Provides explicit conditions for using confirm_destructive and notes blocked statements. Does not explicitly compare with siblings but context implies usage scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get column info and CREATE TABLE DDL for a specific table.
Args: instance_id: The instance name from register_instance. database: The database name. table_name: The table name.
Returns: JSON with {columns: [...], ddl: "..."}, or error details.
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | ||
| table_name | Yes | ||
| instance_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the return format (JSON with columns and ddl) but does not disclose whether the operation is read-only, has side effects, or requires authorization beyond registration. Adequate but not rich.
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 appropriately sized, front-loading the purpose in the first sentence. The argument list and return description are clear and concise, with no wasted 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 presence of an output schema and 3 required parameters, the description covers the essential behavior. It does not mention prerequisites (e.g., instance must be registered) but that is implied by the parameter description. Sufficient for a read-oriented tool.
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 0%; the description lists all three parameters with brief context ('The instance name from register_instance'). This adds some meaning beyond the schema's type-only declarations, but lacks format details 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 verb 'get' and resource 'table detail' (column info and DDL). It distinguishes well from siblings like list_tables (which only lists names) and execute_sql (which runs arbitrary queries).
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 implicitly tells when to use this tool: when column info or CREATE TABLE DDL is needed. It does not explicitly exclude alternative tools, but the sibling names (list_tables, execute_sql) make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all databases on a registered instance.
Args: instance_id: The instance name from register_instance.
Returns: JSON array of database names, or error details.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions listing and returns, but does not explicitly declare read-only nature, error conditions, or side effects. Adequate but not comprehensive.
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 sentences plus structured Args/Returns. Every sentence adds value; no wasted 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 a simple tool with one required parameter and an output schema, the description provides complete enough guidance. Missing details on output shape are covered by output schema.
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 0%, but description adds meaningful context: 'The instance name from register_instance.' Fully describes the single parameter beyond the schema.
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 clearly states 'List all databases on a registered instance' with specific verb and resource. Distinguishes from sibling tools like list_instances or 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?
Implies usage by mentioning 'registered instance' and referencing register_instance in parameter. Does not explicitly state when not to use, but context with siblings is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered database instances.
Returns: JSON array of instances. Passwords are never included.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It confirms the operation is read-only (list) and adds a critical safety note: 'Passwords are never included.' This addresses a key security concern beyond the schema.
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 two sentences: the first states the purpose, the second details output format and an important security guarantee. It is front-loaded, concise, and every sentence adds value.
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?
While the description covers the basic purpose and a security aspect, it does not clarify what constitutes a 'database instance' versus a 'database' (sibling list_databases exists). It also omits any mention of pagination, ordering, or performance implications, though the tool is simple with no parameters.
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 zero parameters, and schema coverage is 100% (trivially). Per the rubric, 0 parameters yields a baseline of 4. No additional parameter info is needed or provided.
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 'List all registered database instances,' specifying the exact resource and action. It distinguishes from sibling tools like list_databases, list_tables, and register_instance by focusing on 'instances' rather than databases or 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?
The description provides no guidance on when to use this tool versus alternatives. It lacks explicit when-to-use, when-not-to-use, or alternative tool references, leaving the agent to infer context solely from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tables in a database with row count and size.
Args: instance_id: The instance name from register_instance. database: The database name to list tables from.
Returns: JSON array of {table, rows, size_mb, engine, comment}, or error.
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | ||
| instance_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It states the return format and hints that instance_id comes from register_instance, implying a prerequisite. However, it does not disclose potential side effects, performance considerations, or error cases.
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 extremely concise with no wasted words. It front-loads the purpose and structures arguments and returns in a clear, scannable format.
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 existence of an output schema (indicated by context), the description need not detail return values. It provides a good summary of the return structure and covers the key behavior. Minor gaps: no mention of ordering, pagination, or error conditions.
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 0%, so the description must explain parameters. It does so concisely: 'instance_id: The instance name from register_instance. database: The database name to list tables from.' Both parameters are fully described.
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 'List tables in a database with row count and size', providing a specific verb and resource. It distinguishes from siblings like 'execute_sql' and 'get_table_detail' by implying a broad listing, but does not explicitly differentiate.
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 vs alternatives. The description does not mention when it is appropriate or inappropriate, nor does it reference sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a MySQL-compatible database connection at runtime.
Tests the connection with SELECT 1 before caching. If a connection with the same name already exists, it is closed and replaced.
Args: name: A human-readable identifier for this instance (used as instance_id). host: Database host or IP address. port: Database port (e.g. 3306). user: Database username. password: Database password. database: Optional default database/schema. charset: Connection charset, defaults to utf8mb4.
Returns: JSON string with instance_id and status, or error details.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| name | Yes | ||
| port | Yes | ||
| user | Yes | ||
| charset | No | utf8mb4 | |
| database | No | ||
| password | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses testing with SELECT 1 and replacement of existing connections; no annotations provided, so description carries burden well, though omits potential side effects or concurrency handling.
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?
Well-structured with Args section but slightly verbose; could be trimmed while retaining clarity.
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?
Covers purpose, behavior, and return value; output schema exists, so description is adequate; no major gaps identified.
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?
With 0% schema coverage, description thoroughly explains each parameter's meaning, including defaults for charset and database, adding significant value beyond the schema.
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?
Clearly states it registers a MySQL-compatible database connection at runtime, distinguishing it from siblings like execute_sql and list_instances.
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?
Explains connection testing and replacement behavior but lacks explicit guidance on when to use vs alternatives, e.g., when a connection object is needed.
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.
v0.1.0execute_sqlget_table_detaillist_databaseslist_instanceslist_tablesregister_instanceEach tool has a distinct and non-overlapping purpose: registering instances, listing instances, listing databases, listing tables, getting table details, and executing SQL. No ambiguity between tools.
All tools follow a consistent verb_noun pattern with snake_case (e.g., execute_sql, get_table_detail, list_databases). No mixing of conventions.
With 6 tools, the server is well-scoped for managing and querying MySQL databases. It covers essential operations without being bloated or too sparse.
The tool set covers core discovery and query workflows, and destructive operations are possible via execute_sql with confirmation. Minor gaps include no dedicated unregister/update instance tool and no separate create/drop database/table tools, but these are manageable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
PostgreSQL, MySQL, OpenAPI/Swagger, and shared Agent Memory with scoped access.
Database for your AI agent. Turn its output into data, docs, skills, and apps you can actually use.
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yangfeng20/dynamic-db-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
