Loading ToolBench
MCP server for executing SQL queries and retrieving metadata from Oracle databases
The server has 5 properly registered tools with descriptions and basic input schemas. However, parameter descriptions are minimal or absent in most tools, output schemas are not documented, and error handling returns raw exceptions rather than actionable guidance. Tool names follow verb_noun convention well (execute_sql, get_schemas, get_tables, get_table_metadata, validate_and_estimate_cost), but parameter annotations lack the detail needed for reliable LLM invocation. The execute_sql tool particularly lacks guardrails and parameter validation hints. Overall structure is sound but falls short of production quality due to incomplete descriptions and undocumented output formats.
Executes an SQL query on the Oracle Database
Retrieve a list of available schemas (users) in the database
Retrieve column metadata for given schema and table
Retrieve a list of table names for the given schema
Validates an SQL query and returns its execution plan with cost.
Output schemas are not documented. All 5 tools return structured data (lists, dicts) but descriptions do not specify what fields to expect or what format LLMs will receive. This forces LLMs to reverse-engineer response structure from code or errors.
Error handling returns raw exceptions ({"error": str(e)}) without actionable recovery guidance. Call get_schemas() to see available schemas'). Stack traces and raw error strings do not help agents self-correct.
Parameter descriptions are significantly below rubric baseline (avg 72 chars). Most params have 12 - 35 char descriptions that lack format constraints, ranges, or valid value hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 7 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
execute_sql tool has no input validation, SQL injection prevention visible, or guidance on safe vs unsafe queries. Tool description does not warn that tool executes arbitrary SQL (safety concern). No mention of rate limits, timeout, or result limits despite using .fetchmany() with no explicit size cap.
validate_and_estimate_cost tool combines two distinct concerns (validation + cost estimation) in one tool name using 'and' connector.
No permission gates or audit logging visible. Tool descriptions do not declare required permissions (e.g., read:oracle_db, execute:sql). execute_sql can run any SQL (SELECT, DELETE, DROP) without role-based checks. No caller identity or audit trail in responses.