Loading ToolBench
A Model Context Protocol server for MySQL database operations with Server-Sent Events (SSE) transport, providing comprehensive database query, metadata, and schema inspection tools with security controls.
The server implements 12 database query and metadata tools with reasonable schemas and descriptions. However, significant gaps exist: descriptions are translated from Chinese and sometimes unclear in English, parameter documentation is inconsistent, output schemas are not explicitly documented, error handling lacks recovery guidance, and security features (tool annotations, permission gates) are absent. The codebase shows defensive programming (parameter validation, sensitive data filtering) but the MCP interface itself does not expose these safeguards through tool metadata. Average tool quality lands at 58, solidly in the 'Fair' category with noticeable gaps typical of community servers.
描述表结构
分页执行查询以处理大型结果集
执行MySQL查询并返回结果
获取表的列信息
获取表的创建语句
获取所有数据库列表，支持筛选和限制结果数量
获取表的外键约束信息
获取表的索引信息
Missing output schema documentation. No tool explicitly documents what fields are returned or their types. LLMs cannot plan downstream tool calls or extract relevant fields without knowing return structures. E.g., mysql_show_databases returns a list but the structure of each item is not documented.
Weak parameter descriptions. Many parameters have translations that are ambiguous or lack actionable constraints. E.g., mysql_show_columns: 'table' parameter has no description at all. 'pattern' parameters appear in 6 tools but lack examples or regex syntax. No mention of format (SQL LIKE syntax?), valid character sets, or length limits.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
获取MySQL服务器状态
获取表状态信息
获取数据库中的表列表，支持筛选和限制结果数量
获取MySQL系统变量
Missing error handling guidance. Tools return errors as JSON (e.g., ParameterValidationError, QueryExecutionError) but provide no recovery suggestions. When a query fails, LLM receives 'error: "query execution failed: ..."' with no indication of whether to retry, adjust parameters, or ask the user. Violates error-classification and recovery-guide patterns.
mysql_query tool lacks destructive operation warning. This tool can execute INSERT, UPDATE, DELETE, DROP, and other state-changing SQL. The description says only 'execute MySQL query' with no mention that the tool modifies state or guidance on dry-runs. No toolAnnotations (destructiveHint=true) declared in MCP. Violates command-tool and confirmation-request patterns.
No tool annotations for read-only vs destructive operations. MCP spec supports readOnlyHint, destructiveHint, and idempotentHint in tool metadata. None are declared. LLMs cannot automatically gate mysql_query or distinguish safe metadata reads (mysql_show_databases) from risky mutations.
Sensitive data exposure via tool response. The code in mysql_info_tool.py attempts to filter sensitive info (passwords, auth, keys) on the server side, but the filtering logic is incomplete and never reaches the filtered result, the response building breaks at line 'if value_field in filtered_item:' without writing sensitive values back. This means intended safeguards don't actually prevent secrets from leaking into LLM context.
No pagination limits declared. mysql_paginate_results and mysql_show_databases accept 'limit' but no max is enforced in the schema (limit=0 means 'no limit'). Large result sets can exhaust context windows. Schema should cap limit to a reasonable maximum (e.g., 1000) and document it.
Parameters lack type constraints and validation messages. E.g., 'limit' in mysql_show_databases accepts integer but no min/max is declared in schema. 'page' in mysql_paginate_results has no minimum (page 0? -1?). Parameter descriptions in code mention constraints (e.g., 'default 100') but schema doesn't enforce them.
Tool naming could be more action-oriented. Names like 'mysql_show_databases' vs 'mysql_list_databases' are not wrong, but 'show' is database-jargon and less action-verb than 'list'. Consistency is weak: 'mysql_describe_table' uses describe, 'mysql_show_columns' uses show. Pattern suggests 'get_', 'list_', 'describe_' be used consistently.
mysql_query description is vague and does not convey scope or limitations. 'Execute MySQL query' does not hint that this tool can modify state, that prepared parameters are supported, or what types of queries are safe vs unsafe. Description should explicitly state 'Executes any SQL query (SELECT, INSERT, UPDATE, DELETE, etc.)' and warn about mutation side effects.