Loading ToolBench
This server provides tools to parse SQL statements into a tree structure using future-architect/tree-sitter-sql. Use the 'parse_sql' tool to strictly parse SQL statements, or 'parse_sql_with_error_recovery' to parse and return the tree including ERROR nodes for error recovery.
Both tools have minimal descriptions (under 50 chars) and identical, overly simple parameter schemas. No output schema documentation. Descriptions lack context on when to use each tool, what they return, or how they differ. Parameter descriptions are generic. No error recovery guidance. Tools lack the depth expected for production use.
Parse sql
Parse sql with error recovery (including ERROR node)
Descriptions are critically short (8-50 chars) and lack actionable context. 'Parse sql' and 'Parse sql with error recovery' do not explain WHEN to use each tool, what the output structure is, or how error handling differs. LLMs cannot reliably select between them.
No output schema documented. Tools return text via Content::text(result), but LLMs have no visibility into the tree structure format (indentation, node format, position notation). Downstream tools cannot parse or validate the output.
Parameter descriptions are generic ('sql text to parse'). No guidance on input constraints: max length, character encoding, SQL dialect support, or expected format. LLMs cannot validate inputs before calling.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | <=2025-11-25 | v2 |
Error handling is minimal. parse_sql returns 'Failed to parse sql' with no guidance on recovery. No indication of which SQL constructs fail, whether retry helps, or what the user should do. Error messages do not match the recovery-guide pattern.
Tool naming lacks clarity on differentiation. 'parse_sql' vs 'parse_sql_with_error_recovery' is verbose and does not clearly signal the functional difference (strict vs lenient parsing). Names should be more concise and distinct.