A Model Context Protocol (MCP) server that utilizes XiyanSQL with databases. This server enables AI assistants to list tables, read data, and execute natural language queries
Single tool 'get_data' has minimal definition quality. Input schema exists with basic structure but lacks parameter descriptions, critical gap. No output schema documented. Tool name lacks clarity on what 'data' means or how it differs from other potential data-fetching tools. No error handling guidance, no pagination support despite database queries potentially returning large result sets. Code shows SQL generation and execution but tool definition does not expose this complexity or constraints to the LLM.
Fetch the data from database through a natural language query
Tool description is 28 characters ('Fetch the data from database through a natural language query'), below the 20-char hard threshold. Provides no context on when to use this tool vs alternatives, what 'data' means, or what the LLM should expect back.
Input parameter 'query' has no description in the schema. Rubric requires every parameter to have a non-empty description explaining what it controls. LLM cannot infer whether 'query' expects SQL, natural language, or a specific format.
No output schema documented. Tool returns results from SQL execution but LLM has no visibility into the structure (fields, types, pagination). Rubric requires documented return types for all A+ tools; absence forces LLM to guess and wastes tokens parsing unstructured output.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 33 | <=2025-11-25 | v2 |
Tool name 'get_data' is generic and ambiguous. Does not follow verb_noun pattern clearly (get_database_query_results would be clearer). Baseline production tools average 18 chars; 'get_data' at 8 chars is too terse and conflates multiple concerns (schema discovery, data fetching, SQL generation).
No error handling guidance. Code shows SQL generation can fail and attempts retry logic, but tool definition provides no recovery hints. Try rephrasing with table names from schema.').