Loading ToolBench
An MCP server for executing SQL queries and managing MySQL databases with profile-based access control, table access gating, and secure credential handling.
This MySQL MCP server provides 8 tools with reasonable input schemas and some descriptions, but has critical gaps in parameter documentation, naming consistency, and error guidance. Tools are explicitly registered with JSON Schema validation via Zod, but parameter descriptions are inconsistently detailed and often rely on Korean language explanations that may not parse clearly for LLM intent detection. Output schemas are defined (e.g., showIndexesOutput in show_indexes.ts), but error handling is minimal, errors are logged to stderr but do not provide actionable recovery guidance to the agent. Naming is verb-noun style (query, execute, show_tables, describe_table) which is good, but some parameter descriptions are too generic or assume prior context. The profiles tool returns connection state, which is valuable for discovery, but the tool composition around profile selection is verbose, every tool repeats the same long profile parameter description verbatim. No tool annotations (readOnlyHint, destructiveHint) are present, despite clear intent differences (execute is WRITE, others are READ_ONLY).
Describe the schema and comments for a given table
Execute a non-SELECT SQL (DDL/DML) and return affected rows, insertId, warnings. 읽기 전용 프로파일에서는 거부된다.
Return the execution plan for a SELECT statement
조회할 수 있는 DB 프로파일과 각각의 열림 상태를 돌려준다. 어느 프로파일로 물어야 할지 모를 때, 또는 프로파일이 닫혀 있다는 응답을 받았을 때 부른다. open=false 인 프로파일은 사용자가 열어야 하며 Agent 가 열 수 없다.
Execute a SELECT query and return rows with column metadata
Show index definitions for a given table
List tables in the current database (optionally include views)
All tools lack tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked with risk:READ_ONLY vs risk:WRITE in metadata, but not via Zod-backed tool annotations that MCP clients can parse. The execute tool is destructive and should signal this to prevent accidental misuse by agents.
Parameter descriptions are verbose, repetitive, and largely identical across all tools. The profile parameter repeats a 200+ character explanation in every tool. This violates DRY (Don't Repeat Yourself) and bloats the schema. Additionally, profile descriptions include Korean language text and assume the LLM knows profiles.json structure, not universally clear.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Return the MySQL server version string
Error handling is minimal. Tools catch exceptions and log to stderr, but do not return actionable error messages to the agent. Example from show_indexes.ts: catch block logs stack trace but re-throws the original error with no recovery guidance. An agent needs to know: is this retryable? Should I try a different table? Did I misspell the profile? The error response must guide the LLM's next step.
Parameter names assume prior context. The 'maxRows' parameter in query tool lacks clear guidance on what happens when the query result exceeds maxRows, is it truncated silently? Does it error? The description says '(プロファイル上限を超えられない)' [cannot exceed profile limit], but this is vague and in Japanese.
The 'version' tool is minimally documented ('Return the MySQL server version string'). It does not explain why an agent might call it (e.g., to detect feature compatibility) or what format the version string is in. At 50 characters, the description is below the recommended 10-1024 character range midpoint and lacks context for LLM selection.
No confirmation step for destructive operations. The execute tool modifies database state (INSERT, UPDATE, DELETE, DDL) but provides no dry-run or confirmation mechanism. An agent could accidentally drop a table. Agents make mistakes, a confirmation step prevents catastrophic errors.
Output schema for query and execute tools is not visible in the source code provided. The show_indexes tool explicitly defines outputSchema as showIndexesOutput, but query and execute tools do not show explicit output schema definitions. If they are inferred or generic, LLMs cannot plan downstream tool chains effectively.