MySQL query and metadata information server with SSE transport
This MySQL MCP server exhibits significant gaps in definition quality across multiple dimensions. While tool naming is generally clear with action verbs (mysql_query, mysql_show_*), descriptions are inconsistent in language (mixing Portuguese, Chinese, and English), and many lack the depth needed for LLM tool selection. Critically, parameter descriptions exist but are often vague regarding formats, constraints, and allowed ranges. Input schemas are present but lack critical elements like minimum/maximum bounds for numeric parameters, enums for constrained inputs (e.g., sort order, output format), and clear documentation of mutual dependencies. Output schemas are completely undocumented, LLMs have no visibility into what these tools return, preventing proper planning of downstream calls. Error handling is minimal, with generic exception classes and no actionable recovery guidance. The server lacks idempotency markers, permission declarations, and security-focused parameter validation descriptions. The code shows attempt at error handling through decorators, but errors return generic JSON without guidance on what went wrong or what the LLM should do next.
Descreve a estrutura de uma tabela
Executa consulta com paginação para lidar com grandes conjuntos de resultados
Executa consulta MySQL e retorna os resultados
Obtém informações das colunas de uma tabela
Obtém o comando CREATE TABLE para uma tabela
获取所有数据库列表,支持筛选和限制结果数量
Obtém informações sobre as constraints de foreign key de uma tabela
No output schemas documented for any tool. LLMs have zero visibility into response structure, preventing proper planning of tool chaining and data extraction.
Inconsistent description language (Portuguese, Chinese, English) makes the server hard to use in English-dominant LLM environments. Descriptions should be in a single language (English preferred for code/API contexts).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Obtém informações sobre os índices de uma tabela
获取MySQL服务器状态
Obtém informações de status das tabelas
Obtém lista de tabelas do banco de dados, com suporte a filtro e limitação de resultados
获取MySQL系统变量
Numeric parameters lack explicit min/max bounds. Parameters like 'limit', 'page', 'page_size' do not specify ranges, allowing LLMs to pass absurd values (999999 records, page 1000000) that break the service.
No error handling guidance in tool descriptions. When a query fails or a table/database is not found, the LLM receives generic exceptions without actionable recovery hints. Code shows ParameterValidationError and QueryExecutionError classes but descriptions don't explain when/how to use them.
Security filtering (sensitive variables redacted in production, per code in mysql_info_tool.py) is not disclosed in tool descriptions. LLMs expect certain variables (password, ssl_key) but may be silently omitted, causing confusion and wasted retries.
No distinction documented between similar tools (mysql_show_columns vs mysql_describe_table). Both query table structure, when should the LLM use one vs. the other? Without clear differentiation, the agent wastes reasoning cycles or picks wrong.
Parameter descriptions use SQL-specific examples (LIKE syntax '%test%') but don't state that constraint explicitly. LLMs may not recognize LIKE syntax as a requirement vs. a suggestion.
mysql_query and mysql_paginate_results accept arbitrary SQL without documented constraints. Risk of SQL injection via prompt injection is high. Descriptions should state: 'Only SELECT queries are supported' or document that parameterized queries are required.
No idempotency markers or dry-run options. mysql_query can execute UPDATE/DELETE/INSERT (WRITE risk) without confirmation. Agents may accidentally modify data on retry.