Loading ToolBench
A read-only MCP server for querying and inspecting Oracle databases. Provides tools for executing SELECT queries, listing tables and objects, retrieving schemas, and accessing PL/SQL source code.
Oracle MCP server has 6 tools with consistent verb-noun naming (sql-select, list-tables, get-table-schema, list-objects, get-object-source, list-jobs). All tools have descriptions (avg 94 chars), exceeding the 10-char minimum. However, most parameter descriptions are minimal or absent. Input schemas are present and typed (string parameters with required flags), but lack formal constraints (enums, ranges, formats). No output schemas are documented, responses are free-text JSON without field specifications. Error handling returns generic error strings without recovery guidance. Security appears sound (read-only operations, no credentials in params). Tools are well-composed (single responsibility, appropriate names), but lack the formal structure and parameter constraint documentation expected of A-grade tools.
Get the PL/SQL source code for a stored procedure, function, package, type, or trigger
Get the schema (column definitions) for a specific table
List all Oracle Scheduler jobs
List all Oracle objects of a specific type. Valid types: PROCEDURE, FUNCTION, PACKAGE, PACKAGE BODY, TYPE, TYPE BODY, TRIGGER, VIEW, SEQUENCE, INDEX, SYNONYM, TABLE
List all tables accessible to the current user (excluding system tables)
Execute a SELECT SQL query against the Oracle database. Queries are limited to 1000 rows.
Missing enum constraints on object_type parameter (list-objects, get-object-source). Description lists valid values as text, but no formal enum schema. LLMs cannot distinguish hallucinated values from valid ones.
No output schemas documented for any tool. Responses are returned as free-text JSON strings without field specifications. LLMs cannot plan downstream tool calls or extract required data (e.g., which fields are present in table schema results).
Minimal or absent parameter descriptions. Most parameters (e.g., 'query' in sql-select, 'table_name' in get-table-schema) have descriptions, but they are too brief to guide LLM usage. No details on constraints, expected format, or dependencies.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error responses lack recovery guidance. Example: 'Database error: <message>' provides no hint about whether to retry, call a different tool, or ask the user. Errors should classify as retryable/user-fixable/fatal and suggest next steps.
No pagination or result limits documented in tool descriptions. sql-select mentions '1000 row' limit in description, but list-objects and get-object-source do not advertise result caps. Large unbounded result sets risk exhausting context windows.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only, but this is not formally declared in the schema. Clients cannot distinguish safe tools from destructive ones without parsing descriptions.