Loading ToolBench
MySQL/MariaDB MCP server for executing read and write queries with safety controls and transaction management
MCP Go MySQL has 10 tools with complete input schemas and clear descriptions. Tool naming follows verb_noun conventions (query, execute, tables, describe, etc.), which is appropriate. Descriptions range from 94-185 characters, within the 10-1024 baseline. However, the server has significant gaps: (1) NO output schemas are documented for any tool, violating the 'Document the output schema' critical check. LLMs have no way to know what fields to expect from responses, breaking downstream tool composition. (2) Error handling is minimal, no recovery guidance, no actionable error messages shown in code. (3) Parameter constraints are weak: the 'execute' tool has a 'confirm_key' parameter with zero guidance on how to generate it or what values are valid. (4) The 'sample' tool mentions 'default: 10, max: 100' in description but this is not enforced via minItems/maxItems in the schema. (5) Security concern: the 'execute' tool references MAX_SAFE_ROWS in the description but this constant is not defined in the visible code and no validation logic is shown. (6) Composition: tools like 'query', 'execute', and 'sample' all return unstructured strings (per visible code), losing structured data needed for chaining. The server is well-organized and functional, but lacks production-grade output design and error guidance.
Count rows in a table. For filtered counts, use 'query' with SELECT COUNT(*) ... WHERE.
Get information about the current database connection and server.
Describe the structure of a specific table, including columns, types, keys, and constraints.
Execute an INSERT, UPDATE, or DELETE query inside a transaction. Operations affecting more than MAX_SAFE_ROWS rows require confirm_key; without it the transaction is rolled back and no changes persist.
Explain the execution plan for a query.
Show indexes for a specific table.
Execute a SELECT query on the MySQL database. Only SELECT queries are allowed for safety.
NO output schemas documented for any tool. All 10 tools return unstructured strings. LLMs cannot parse responses or extract fields needed for downstream tool calls. This violates the critical 'Document the output schema' check and breaks tool composition.
Error handling provides no recovery guidance. Code shows 'return "", fmt.Errorf(...)' with no actionable messages. LLMs receive raw errors with no hint on what to do next (retry, call a different tool, ask user, etc.). Violates 'Error responses must tell the LLM what to do next' critical check.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 63 | - | v1 |
Get a sample of rows from a table (default 10 rows).
List all tables in the current database with their metadata (type, engine, row count, comments).
List all views in the current database.
'execute' tool references MAX_SAFE_ROWS in description but no constant or validation shown in code. The confirm_key parameter has zero guidance on how to generate it or what makes a valid key. Violates 'Describe the expected format, range, and allowed values directly in the parameter description.'
'sample' tool description mentions 'max: 100' but schema has no maxItems constraint. The 'limit' parameter has no minItems/maxItems in InputSchema to enforce bounds. LLMs may pass values outside the documented range.
No pagination support visible. Tools like 'query' could return thousands of rows but no limit or offset parameters shown.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared in InputSchema. Tools clearly have different safety profiles (query/describe are read-only; execute is destructive) but these are not formally declared. Agents cannot reason about safety without explicit annotations.