Loading ToolBench
MCP server for executing SQL queries and retrieving schema information from Cloudera Impala databases, with support for Apache Iceberg tables
This MCP server has fundamental definition quality gaps. Both tools have descriptions and basic verb naming, but input parameter descriptions are almost entirely missing, schemas lack type information, and error handling provides no recovery guidance. The execute_query tool has a string parameter but no parameter-level description explaining what SQL is valid or what format is expected. The get_schema tool has no parameters, so its schema is trivial. Output schemas are completely undocumented, LLMs cannot plan downstream calls without knowing what fields to expect. Security is a significant concern: the server implements only rudimentary SQL injection prevention (a simple prefix check) which is insufficient for production use. Error messages are generic ('Error: {str(e)}') and provide no actionable guidance. The server follows basic verb_noun naming (execute_query, get_schema) but falls short on all other Definition Quality dimensions.
Execute a SQL query on the Impala database and return results as JSON.
Retrieve the list of table names in the current Impala database.
Input parameters lack descriptions. The 'query' parameter in execute_query has no description explaining what SQL is valid, what format is expected, or what constraints apply (read-only prefixes, length limits, etc.). LLMs cannot reliably infer this from the parameter name alone.
Output schemas are completely undocumented. execute_query returns a JSON string, but the schema of that JSON (field names, types, structure) is not documented. get_schema returns a JSON array, but the array element type is not specified. Without documented output schemas, LLMs cannot plan multi-step workflows or extract the right data.
SQL injection prevention is inadequate. The implementation uses only a simple prefix check ('select', 'show', 'describe', 'with') which can be bypassed with comments or nested queries. This is explicitly flagged in the code as needing improvement for production use. A more robust parameterized query approach or SQL parser is required.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Error messages provide no recovery guidance. When execute_query fails with 'Error: {str(e)}', the agent receives a raw exception message (e.g. 'Connection refused') with no hint about what to do next (retry? check credentials? reduce query complexity?). Per pattern:recovery-guide, errors must tell the LLM what to do.
No pagination support. If execute_query returns a large result set (thousands of rows), the entire result is serialized as JSON, potentially exhausting the context window. No limit parameter, no offset/pagination, no total count is documented.
Credentials exposed in environment variable defaults. The get_db_connection() function uses default values like 'username' and 'password' in os.getenv calls, which suggests credentials are expected from environment variables. If these are not set, hardcoded demo values could leak. Additionally, the code passes credentials as plain text to the connect() function without validation that they were actually read from secure sources.
No permission gating or audit trail. There is no check to verify that the calling agent/user is authorized to execute arbitrary SQL or retrieve schema information. No logging of who called what tool, with which parameters, or at what time. This violates compliance and debugging requirements.
Parameter type information missing from schema. The execute_query tool shows input as {"query":{"type":"string",...}} which is correct at the JSON Schema level, but the actual fastmcp decorator and underlying schema definition are not visible in the provided code. Based on what is shown, schemas appear minimal.
No documentation of return structure. execute_query says it 'return results as JSON' but does not specify: Is it an array of objects? An object with 'rows' and 'columns'? Does it include column names? get_schema says 'Retrieve the list of table names' but does not specify if it returns just names or also schema metadata. Without this, LLMs must guess the structure.