Loading ToolBench
A FastMCP server for retrieving MySQL database schema information. Provides tools to retrieve database list, table list, table schema (columns), table indexes, and table foreign keys.
MySQL Schema MCP has clear, consistent verb-based naming (list_databases, get_table_schema) and complete input schemas across all 5 tools. However, parameter descriptions are minimal (generic placeholders like 'Database name'), tool descriptions lack context on WHEN to use each tool or WHAT downstream actions they enable, and critical information about output structure and error handling is entirely absent from the source. The server handles a narrow read-only domain (MySQL schema inspection) with appropriate tool composition, but lacks the rich documentation and error guidance expected of production-grade tools. Base calibration: descriptions and error handling are below median quality for the 549 production baseline (194 chars avg), and no per-parameter constraints are enforced beyond nullable flags.
List all databases in the MySQL server.
Get the foreign keys for a specific table.
Get the indexes for a specific table.
Get the schema (columns, indexes, foreign keys) for one or more tables.
List all tables in a database. If no database is provided, lists tables from all databases.
Tool descriptions lack context on WHEN to use and what downstream actions they enable. E.g. 'List all databases in the MySQL server' (51 chars) does not explain when an LLM should call this vs. starting with 'tables' or 'schema'. No guidance on typical query sequences (discover_database → list_tables → get_schema) or preconditions.
Parameter descriptions are trivial placeholders ('Database name', 'Table name', 'List of table names'). No format constraints, examples, or dependencies documented. E.g. the 'database' parameter in 'tables' tool is nullable but no guidance on what 'all databases' means when omitted, or whether behavior differs from explicit specification.
No output schema documentation visible in tool definitions. The source shows Pydantic models (DatabaseInfo, TableInfo, ColumnInfo, etc.) but MCP tool definitions (presumed in FastMCP registration) do not document what fields are returned. LLMs cannot plan downstream calls without knowing output structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
No error handling guidance. Tool implementations likely fail on connection errors, invalid database names, or permission denials, but no recovery paths documented. E.g. 'Database not found, call databases() to list available schemas' is absent.
Tool names use ambiguous 'schema' (the tool 'schema' gets table schema; 'schema' also means database schema). 'get_table_schema' would be clearer. The 'schema' tool could collide with terminology referring to the database schema itself, risking LLM confusion.
No pagination support on tools returning lists (databases, tables, schema with multiple tables). Large MySQL instances with hundreds of databases/tables will return unbounded results, risking context window exhaustion. No limit parameter or result capping visible.
The 'schema' tool takes an array of table names but no guidance on how many tables can be queried in one call. If a large array is passed, behavior is undefined (timeout? memory exhaustion?). Describe max batch size and recommend pagination.