Loading ToolBench
This server has severe definition quality gaps. Both tools have descriptions, but they are critically under-specified for LLM use. The execute_query tool is particularly problematic: it accepts arbitrary SQL with zero input validation, no enum constraints, no format guidance, and no parameter description beyond the SQL string itself. Neither tool documents output schemas. The list_oracle_tables tool has an empty input schema (no parameters), which is acceptable, but lacks any guidance on pagination or result limits. Error handling is present but generic, it returns Oracle error codes without recovery guidance. The descriptions are too brief (10-16 chars for tool descriptions; 0 chars for the execute_query parameter description) to serve as LLM selection hints. No tool annotations (readOnlyHint/destructiveHint) are present despite one tool being explicitly READ_ONLY and the other IRREVERSIBLE. No output schema documentation exists.
Execute any SQL command.
Lists all tables in the Oracle database.
execute_query tool accepts arbitrary SQL with zero input validation or constraint documentation. The 'sql' parameter has a bare type declaration (string) but NO description of valid formats, constraints, or examples. LLMs will pass unvalidated SQL directly to the database.
Missing output schema documentation for both tools. LLMs cannot plan downstream operations or extract specific fields without knowing the structure of the response. list_oracle_tables should document that it returns an array of table names; execute_query should document that it returns either rows (for SELECT) or rowsAffected (for DML).
Tool descriptions are too brief to serve as LLM selection hints. 'Lists all tables in the Oracle database.' (43 chars) and 'Execute any SQL command.' (24 chars) lack WHEN to use this tool, what it returns, and prerequisites. Baseline is 194 chars; these are 4 - 5× too short.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
No tool annotations (destructiveHint, readOnlyHint) despite execute_query being marked IRREVERSIBLE and list_oracle_tables being READ_ONLY. LLMs have no explicit signal that execute_query modifies state and should not be retried blindly.
Error handling lacks recovery guidance. When execute_query fails with 'ORA-00942' (table not found), the code appends a TIP, but this is hardcoded and incomplete. Generic Oracle errors (ORA-00000) return no guidance. LLMs need structured error responses with actionable next steps.
No pagination or result limits for list_oracle_tables. If the database has thousands of tables, the response will be huge, wasting tokens and potentially exhausting context. Should accept optional limit and offset parameters and document the max default result size.
execute_query parameter 'sql' lacks any description. Parameter descriptions are mandatory per the rubric (100% of A+ tools have param descriptions). LLMs cannot infer whether to pass raw SQL, parameterized queries, or other formats without explicit guidance.
No SQL injection or command injection safeguards documented or enforced. The tool calls execute() directly on user-provided SQL with zero validation. While the MCP server runs in a controlled environment, the absence of any validation guidance increases risk if this pattern is copied elsewhere.