Loading ToolBench
A Model Context Protocol server for generic database operations supporting multiple database dialects (SQLite, PostgreSQL, MySQL, Teradata, Snowflake, Databricks, Neo4j, Oracle). Provides tools for executing queries, managing schemas, and performing data operations with dynamic tool registration.
This MCP server has 12 tools with significant structural and documentation gaps. While input schemas are present for all tools, most parameter descriptions are minimal or absent. Tool names are generally clear and action-oriented (merge, execute, test, etc.), but several critical issues undermine quality: (1) The 'system_run_chain' and 'system_inspect_tool' tools have complex functionality not fully documented in their descriptions. (2) Parameter descriptions are inconsistent, some tools like 'general_merge_tool' have detailed param docs, while others like 'icon_list' and 'icon_assign' lack descriptions entirely or are generic. (3) Output schemas are not documented anywhere in the provided code, only input schemas are defined. (4) Error handling and recovery guidance is minimal across all tools. (5) The 'execute_ddl_tool' requires explicit 'YES' confirmation, which is good for safety, but the tool description does not clearly explain this interaction pattern. (6) No tool annotations (readOnlyHint, destructiveHint) are visible in the source, which are important for agent safety. The server demonstrates intent to build a well-structured toolkit (prompts, resources, dynamic tools, icon management), but execution falls short of production quality. Average tool score: ~38/100.
Create or update a prompt in the PromptRegistry.
Create or update a static resource in the ResourceRegistry.
Execute DDL commands (CREATE, ALTER, DROP, TRUNCATE) with safety checks. Requires explicit confirmation to prevent accidental schema changes.
Upsert data (Insert or Update) based on a key column. Supports SQLite, PostgreSQL, and standard SQL dialects.
Get the last error from the execution log. Returns detailed error information including full Python traceback. Optionally filter by tool_name.
Assign an existing icon to a tool.
List all available icons in the registry.
OUTPUT SCHEMAS NOT DOCUMENTED. None of the 12 tools document what they return. LLMs cannot plan downstream tool calls or extract needed fields without knowing response structure. This violates pattern:tool and pattern:response-shaper.
ERROR HANDLING AND RECOVERY GUIDANCE MISSING. No tool explains what errors can occur, how they are classified (retryable, user-fixable, fatal), or what the LLM should do next. E.g., 'general_merge_tool' can fail if table does not exist, key column is invalid, or JSON is malformed, but no error recovery guidance is provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Save or update an icon. Supports SVG (raw string) or PNG (base64).
Inspect a tool's documentation (manual), schema, and metadata. Critical for verifying how to use complex tools.
Execute a chain of tool calls in sequence with variable substitution. Supports ${step_id.key} syntax to pass results between steps. Validates DAG structure to prevent circular dependencies. Returns detailed error reports showing partial execution on failure.
Update the external documentation (manual) for a tool. Use this to save successful usage patterns.
Test database connectivity and return diagnostic information.
PARAMETER CONSTRAINTS NOT FORMALIZED. Multiple tools include constraints in description text instead of schema enums/patterns. E.g., 'execute_ddl_tool' requires confirmation='YES' (exact capitalization), but the schema does not enforce this with an enum; 'icon_save' format param defaults to 'svg' but does not formally constrain to ['svg', 'png']. This forces LLMs to parse text instead of reading machine-readable constraints.
INCOMPLETE PARAMETER DESCRIPTIONS. 'system_run_chain' param 'args' is described as 'Arguments to pass to the tool. Supports ${step_id.key} variable substitution.' but does not explain the exact syntax, what 'step_id' must be, or how to reference nested fields. LLMs cannot reliably construct variable references without clearer guidance.
EXAMPLE VALUES IN DESCRIPTIONS. 'create_new_prompt' includes example 'review_code' and 'create_new_resource' includes 'memo://project_notes'. LLMs often reuse example values literally rather than adapting to context, causing failed calls. Use enums or constraints instead.
MISSING TOOL ANNOTATIONS. No tools declare readOnlyHint, destructiveHint, or idempotentHint. This is critical for agents to understand which calls are safe to retry. E.g., 'execute_ddl_tool' is destructive and should not be retried without confirmation, but this is not signaled via annotations.
GENERIC PARAMETER DESCRIPTIONS. 'system_inspect_tool' param 'tool_name' is described as 'The name of the tool to inspect' with no guidance on valid format (is it case-sensitive? what if tool does not exist?). 'icon_assign' similarly lacks context (what if icon or tool does not exist?).
IDEMPOTENCY NOT DOCUMENTED. Tools like 'icon_save' and 'create_new_resource' support upsert semantics ('Create or update'), but do not state whether repeated calls with identical inputs produce the same result. Agents retry on ambiguous failures, non-idempotent tools risk duplicate side effects.
PAGINATION AND RESULT LIMITS NOT DOCUMENTED. 'icon_list' returns all icons but does not document result limits or pagination. If the icon registry grows large, responses could exceed context limits. No mention of limit/offset parameters.
VAGUE COMPOSITION SEMANTICS. 'system_run_chain' claims to 'validate DAG structure to prevent circular dependencies' but provides no guidance on how agents should structure chains or what error messages indicate cyclic steps. The 'steps' array structure is under-specified.