Loading ToolBench
Reusable Lakebase MCP Server — Databricks App. Exposes 33 MCP tools with annotations, 2 resources, and 3 prompts over StreamableHTTP. Supports both provisioned and autoscaling Lakebase with auto-detected connection modes.
The server exposes 33 tools with schemas and descriptions, but quality is inconsistent. Tool naming follows verb_noun convention well (list_tables, describe_table, read_query, etc.), which is excellent. However, many descriptions are generic or under-optimized for LLM comprehension. Parameter descriptions exist but lack actionable constraints (ranges, enums, format guidance). Output schemas are not documented in the source code, critical for LLM planning. Error handling guidance is absent. The server mixes READ_ONLY and DESTRUCTIVE tools without confirmation patterns for irreversible operations (delete_records, drop_table, delete_branch). Tool composition is reasonable (each does one thing), but lacks the cross-tool chaining metadata (e.g., returned IDs match downstream tool parameters). Security: no evidence of sanitization against SQL injection in execute_sql, execute_transaction, or read_query, all accept raw SQL strings. This is a significant vulnerability for an agent tool. Average across 33 tools yields ~62; many tools score 50-70 individually due to missing output schema documentation and weak error guidance.
Alter table structure (add/drop columns, rename, constraints)
Batch insert records (optimized for large datasets)
Compare schemas between two branches or databases
Complete database migration workflow (two-phase)
Complete query tuning workflow: apply optimizations, measure improvement
Configure autoscaling settings for an endpoint
No output schema documentation visible in source code. LLMs cannot plan downstream actions without knowing what fields are returned. Critical for tool composition.
execute_sql and execute_transaction accept raw SQL strings with no validation, sanitization, or SQL injection protection. Agents can be prompted to pass malicious SQL (e.g., 'DROP TABLE users') via injection.
Destructive tools (delete_records, drop_table, delete_branch) lack confirmation/dry-run patterns. No recovery guidance in error responses. Agents can permanently destroy data without safeguards.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
Create a new branch from an existing branch or commit
Create a new table with specified columns and constraints
Delete a branch (cannot delete production)
Delete records from a table matching a WHERE condition
Get detailed information about a specific branch (schema, size, commits)
Get detailed information about a specific project
Get detailed schema information for a table (columns, types, constraints)
Drop (delete) a table from the database
Execute arbitrary SQL (SELECT, INSERT, UPDATE, DELETE, DDL, etc.)
Execute multiple SQL statements in a single transaction
Get EXPLAIN ANALYZE output for query optimization
Get current database connection information
Get the connection string for the current/specified database
Get the status and metrics of a specific endpoint
Insert one or more records into a table
List all branches in a project
List all endpoints in a branch
List all Databricks projects in the workspace
List all schemas in the database
Get list of slow queries from pg_stat_statements
List all tables in the current/specified schema
Prepare for database migration: analyze schema, identify incompatibilities
Prepare for query tuning: collect statistics, identify bottlenecks
Generate data quality profile for a table (distribution, nulls, cardinality)
Execute a SELECT query and return results (up to MAX_READ_ROWS)
Full-text search across tables, schemas, and columns
Update records in a table matching a WHERE condition
Credentials (PGHOST, LAKEBASE_PROJECT, tokens) are used from environment variables but no evidence of secret injection pattern or per-tool permission gating. Tokens appear to be passed via headers but scope declarations are absent.
Parameter descriptions lack actionable constraints. E.g., 'batch_size' has no min/max; 'limit' defaults to 10 for list_slow_queries but no bounds stated; 'sample_rows' in profile_table has no constraints. LLMs will pass absurd values.
No error handling guidance visible. Error responses likely return raw database errors (e.g., psycopg2 exceptions) with no actionable recovery steps for the LLM. No classification (retryable vs fatal).
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are attempted via try/except ToolAnnotations import but no visible assignments to Tool objects. Annotations may not be populated.
Pagination not evident in list_* tools. No 'limit', 'offset', 'next_cursor', or total_count parameters/responses visible. Large datasets will exceed context windows.
Tool descriptions do not explain when to use one tool over similar alternatives. E.g., 'read_query' vs 'execute_sql' ambiguity, when should an LLM pick which? No guidance.