Loading ToolBench
MCP server that exposes database tools for SQL query execution, schema inspection, and database management through the Model Context Protocol
vi-sql provides 12 well-named tools with consistent verb-noun patterns (list_, describe_, get_, read_, write_, explain_, open_, update_, sample_). All tools have descriptions (avg ~80 chars, within baseline 34-392). However, input schemas are NOT visible in the provided source code, only tool names and descriptions are shown in tools.go. The code snippet cuts off mid-registration, preventing verification of actual JSON Schema definitions for parameters. This is a critical gap: without seeing the schema definitions, parameter types, constraints, and required flags cannot be validated. The tools appear to follow good naming conventions and cover a coherent domain (database introspection and query execution), but the absence of visible schema definitions forces a conservative score. Error handling, output schemas, and parameter validation are not evident in the excerpt.
Get columns, constraints, foreign keys, and indexes for a table
Return the query plan for a SQL statement. Set analyze=true to also execute and return runtime stats.
Return the result of the last query executed by the user inside the vi-sql app
Return the current editor text from a specific query tab opened by open_query_in_tab. Works regardless of which tab is currently active.
Get database server version, name, and connection info
List all custom enum types and their valid values in the database
List all schemas and their tables in the connected database
Input schemas not visible in source code. Tool registration in tools.go is incomplete, only names and descriptions shown, actual JSON Schema parameter definitions are cut off. Cannot verify parameter types, constraints, required flags, or descriptions.
No output schemas documented. Tool descriptions do not specify what fields or structure the response contains. LLMs cannot plan downstream tool calls or extract required data without knowing response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Open a new query tab in vi-sql and pre-fill the SQL editor with the given query (does not execute it). Returns a tab_id you can later pass to get_query_from_tab.
Execute a read-only SQL SELECT query and return results (up to the configured row limit)
Return up to N rows from a table without writing SQL
Replace the SQL editor content of an existing tab (identified by tab_id) with a new query. Does not execute it.
Execute an INSERT/UPDATE/DELETE/DDL statement. Returns affected row count.
write_query tool lacks confirmation or dry-run capability. Destructive operations (INSERT/UPDATE/DELETE/DDL) should support a confirmation step to prevent accidental data loss. No evidence of pre-execution validation or rollback guidance.
No error handling guidance visible. Tool descriptions do not explain what errors can occur, whether they are retryable, or what the LLM should do next. Error responses must guide recovery.
sample_table and read_query lack pagination guidance. No mention of result limits, offset/limit parameters, or how to handle large result sets. Unbounded results risk context window exhaustion.