Loading ToolBench
An MCP server for SQL database interaction, schema introspection, design, and migration with LLM-powered assistance
SQL Cortex has 9 tools with schemas and descriptions present, but quality is inconsistent. Tool names lack clear action verbs (e.g., 'db.design', 'db.schema.diff' are vague; 'generate_schema_design' would be clearer). Descriptions are present but generic (10-50 chars for most), falling below the 50-200 char LLM-optimized baseline. Critical issue: all tools expose '_context' as a parameter, which is an internal implementation detail that should never be visible to agents, this violates secret-injection and tool-gateway patterns. Parameter descriptions are minimal. Output schemas are not documented in the source. Error handling is absent, no recovery guidance, no categorization. Write tools (db.apply, db.migrate, db.migrate.plan_apply) lack confirmation/dry-run safeguards despite destructive risk. No tool annotations (readOnlyHint, destructiveHint) despite clear risk stratification in the spec.
Execute arbitrary SQL DDL/DML statements against the database
Generate a template for desired database schema design
Execute a migration with optional dry-run mode
Generate a migration plan to transform current schema to desired schema
Generate and optionally apply a migration plan in a single operation
Compare desired schema against current database schema and report differences
Generate and execute an EXPLAIN plan for a SQL query
Internal '_context' parameter exposed to agents. This is a server implementation detail (session_id tracking) that should never be visible in tool schemas. Violates secret-injection and tool-gateway patterns, agents will log and potentially echo this internal state.
Destructive write tools (db.apply, db.migrate, db.migrate.plan_apply) lack confirmation or dry-run safeguards. db.apply accepts arbitrary SQL DDL/DML with no preview. Agents can accidentally drop tables or corrupt data without recovery path.
Tool descriptions are too short (10-50 chars) and lack LLM-optimized guidance. 'Retrieve the schema of the database or a specific table' (52 chars) does not explain WHEN to call this vs db.design or db.schema.diff. Baseline is 50-200 chars with clear differentiation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | <=2025-11-25 | v2 |
Execute a read-only SQL query against the database with optional result limit override
Retrieve the schema of the database or a specific table
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification in spec. Tools marked READ_ONLY, REVERSIBLE, and WRITE in comments but not exposed to MCP protocol. Agents cannot reason about safety without annotations.
No error handling or recovery guidance. Tools return raw errors (e.g., 'Missing sql', 'desired_schema must be an object') without actionable next steps. No categorization of retryable vs fatal errors. Agents cannot self-correct.