Loading ToolBench
A Multi-Cloud Platform (MCP) server that can connect to various database types and execute queries.
The server exposes 8 database tools via FastAPI HTTP transport. While tool names follow verb-noun patterns and most have descriptions, there are significant gaps in parameter schema completeness, parameter descriptions, and output documentation. 6 of 8 tools lack visible input parameter descriptions in the source code. The execute_query tool accepts a complex nested object (ExecuteQueryRequest) but the schema fields are not documented in the source provided. Error handling is present but minimal, most errors return generic HTTP exceptions without recovery guidance. The server handles file uploads and BigQuery/SQLite management reasonably well, but lacks the structured output schemas, pagination guidance, and LLM-specific optimizations expected of production agent tools.
Execute a query on a database. If normalized_query is True, the query will be transformed from its normalized form to its unormalized form.
Get the schema of a database. If return_normalize_schema is True, the schema will be returned in its normalized form. Normalized form refers to the schema of the database in a format that is easier to work with for an LLM. Aka all names are in lowercase and separated by underscores.
Returns a list of all supported database types.
Health check endpoint to verify the API is running.
List all available BigQuery projects (based on uploaded key files).
List all available SQLite databases.
Parameter descriptions missing or incomplete. The execute_query tool accepts a complex ExecuteQueryRequest object but no field-level documentation is visible in the source. get_schema has parameters 'db_info' and 'return_normalize_schema' with minimal descriptions. File upload tools (upload_bigquery_key, upload_sqlite_file) lack guidance on file format constraints beyond the code-level checks.
Output schemas not documented. While tools return JSON responses, the structure and field names are not formally documented. For example, execute_query returns {execution_time, query_result, executed_query} but LLMs have no schema reference to know what query_result contains or how to extract useful data. This forces LLMs to infer structure and risks misinterpreting responses.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Upload a BigQuery service account key file for a specific project. The file will be stored securely and used for BigQuery connections.
Upload a SQLite database file. The file will be stored and can be used for SQLite connections.
execute_query input schema is opaque. The ExecuteQueryRequest type is imported but its fields (db_info, query, normalized_query, unormalized_schema, max_rows, autocommit) are not visible in the provided source. Scoring assumes minimal schema definition based on code patterns. This tool needs explicit schema documentation of all nested fields.
Error responses lack recovery guidance. HTTPException raises with generic status codes and messages (e.g., 'Failed to save key file', 'Failed to list projects') without actionable next steps. Per pattern:recovery-guide, errors should tell LLMs what to try next, retry, call a discovery tool, or ask the user.
No parameter constraints on db_info object. The get_schema and execute_query tools accept a 'db_info' Db_Connection_Args parameter but no enum constraints, required fields, or format guidance is documented. LLMs cannot infer which database types require which connection parameters.
File upload tools lack content validation guidance. While the code checks for .json and .db/.sqlite extensions, there is no description of expected file size limits, character encoding, or what happens if the file is corrupted. LLMs may attempt to upload invalid files without understanding constraints.
No pagination or result limits documented. The execute_query tool accepts a 'max_rows' parameter but does not state what happens if max_rows is very large (e.g., 1M rows). No guidance on pagination, cursors, or recommended limits. Per pattern:paginated-result, tools returning lists should cap results and offer pagination.
No tool annotations for destructive operations. The execute_query tool with normalized_query=False can perform UPDATE/DELETE operations. Per current MCP spec (2026-07-28), WRITE operations should carry destructiveHint=true and ideally support idempotent=false hints. No such annotations are visible.