This server has 6 tools with mixed quality. Tool naming follows verb_noun pattern consistently (read_query, write_query, list_tables, etc.), which is good. However, critical gaps exist: parameter descriptions are minimal or absent, output schemas are completely undocumented, error handling provides no recovery guidance, and security concerns around SQL injection are unaddressed. The MySQL tools accept raw SQL strings with no validation, a significant risk. The weather tool has a description in Chinese, creating accessibility issues. No tool provides pagination for multi-row results. Overall, the server falls into the 'fair' category with significant gaps in description quality and output documentation.
Tools (6)
create_tablewritesource verified58/100
Create a new table in the database
describe_tableread onlysource verified63/100
Get the structure of a specific table
get_weatherread onlyauthsource verified52/100
获取指定城市的当前天气
list_tablesread onlysource verified57/100
List all tables in the database
read_queryread onlysource verified67/100
Execute a SELECT query to read data from the database
No error handling guidance. Tool docstrings do not explain what errors are possible, how to categorize them (retryable vs fatal), or what recovery steps to take.
Document output schemas for all 6 tools. For read_query: return {"rows": [{...}], "row_count": int, "columns": [string]}. For write_query: {"affected_rows": int, "last_insert_id": int | null}. For list_tables: {"tables": [string], "total": int}. For describe_table: {"columns": [{"name": string, "type": string, "nullable": bool, "key": string}]}. For get_weather: {"location": string, "temperature": number, "condition": string, "humidity": number}.
Sanitize SQL inputs: use parameterized queries (e.g., SQLAlchemy text() with bound parameters) to prevent injection. Never concatenate raw user input into SQL strings. Document in tool descriptions: 'Queries are automatically parameterized. Use ? placeholders for values (e.g., SELECT * FROM users WHERE id = ?).'
Add parameter descriptions in English. For 'query' param: 'A valid SQL SELECT/INSERT/UPDATE/DELETE statement. Use parameterized syntax: SELECT * FROM table WHERE id = ? (value passed separately as a parameter).' For 'location' in get_weather: 'City name in English or ISO country code. Examples: Beijing, New York, JP (Japan).'
Implement pagination for list_tables and read_query. Add optional 'limit' (default 20, max 100) and 'offset' (default 0) params. Return {"results": [...], "total": int, "limit": int, "offset": int} so agents know how many more rows exist.
Replace get_weather description with English: 'Get current weather for a specified city. Returns temperature, condition, and humidity. Use city names (e.g., Beijing, New York) or ISO country codes.'
get_weather description is in Chinese ('获取指定城市的当前天气'). English-only descriptions are required for international agent interop. This blocks non-Chinese-speaking agents from understanding when/why to call this tool.
Parameter descriptions are absent or minimal. The 'query' parameter in read_query, write_query, and create_table lacks guidance on format, constraints, or valid SQL dialects. The 'location' parameter in get_weather is described only as '城市名称' (city name in Chinese), failing to specify format (e.g., 'Beijing', 'BJ', or full name required?).
No tool for querying database metadata (schema, indexes, foreign keys). describe_table only shows structure, agents cannot discover relationships or constraints without extra SQL knowledge. Add a tools like 'get_table_relationships' or 'get_column_constraints' to guide agent planning.
describe_table
Split write_query into three focused tools: create_record (INSERT), update_record (UPDATE), delete_record (DELETE). This clarifies intent and lets agents reason about side effects per tool.
Add confirmation/dry-run support for destructive operations. Add optional 'dry_run' param (default false) to write_query and create_table. When true, return what would happen without executing. Document: 'Set dry_run=true to preview changes before committing.'
Add error recovery guidance in descriptions. E.g., read_query: 'If the query fails, check syntax. Common errors: missing table names, invalid column references. Call describe_table to verify schema.' write_query: 'If a constraint violation occurs, call describe_table to check primary keys and foreign keys.'
Add tool annotations (tool hints from MCP spec) to clarify side effects: mark read_query and list_tables with readOnlyHint: true; mark write_query, create_table, delete_record with destructiveHint: true.
Add audit logging. Log who invoked each tool, with which parameters, at what time, and what the result was. Document in server logs or a separate audit table. Example: 'Tool: read_query, User: agent-123, Query: SELECT * FROM users, Timestamp: 2024-01-15T10:30:00Z, Rows: 42.'
Add a describe_database tool to discover all tables, views, and relationships without SQL knowledge. Return {"tables": [{"name": string, "row_count": int, "type": 'table'|'view'}], "version": string}.
Document all error codes and recovery steps. E.g., 'Query timeout (>30s): Check for inefficient JOINs or missing indexes. Try limiting result set or breaking into smaller queries.' Add these to tool descriptions.