Loading ToolBench
Tools for linting Snowflake SQL queries and files with sqlfluff. Use `lint_snowflake_query` for ad-hoc SQL and `lint_snowflake_file` for repository files.
The server implements two focused SQL linting tools with well-structured Pydantic models and clear parameter schemas. Tool names are action-verb based and unambiguous. Descriptions are present and adequate (100-150 chars each), explaining the core function and use case. Input schemas include proper type declarations and descriptions. Output schemas are comprehensively documented via LintResult and LintIssue Pydantic models with field descriptions. Error handling returns structured LintResult objects with status/summary fields that provide some recovery guidance. However, the descriptions lack specific guidance on when to choose one tool over another, parameter constraints could be more explicit (e.g., file path format, size limits), and error messages in the code do not consistently guide the LLM toward recovery actions. Security is solid (READ_ONLY risk, no credential exposure), but there is no explicit rate limiting or validation messaging for invalid SQL file paths.
Lint a Snowflake SQL file from the repository using sqlfluff.
Lint an in-memory Snowflake SQL query using sqlfluff.
Descriptions lack differentiation guidance and recovery hints. Both tools describe their core function but omit context on when to choose one vs. the other, and what to do if linting fails (e.g., 'if you only have inline SQL, use lint_snowflake_query').
Parameter descriptions lack explicit format/constraint guidance. The 'query' parameter for lint_snowflake_query has no hint about query length limits, valid SQL dialects, or complexity constraints. The 'path' parameter for lint_snowflake_file has no explicit format (relative vs. absolute), extension requirement (.sql), or size warnings.
Error handling messages are generic and do not guide LLM recovery. When a file is not found or path is outside workspace, the exception is caught and wrapped in a LintResult with status='error', but the summary does not suggest recovery steps (e.g., 'Path must be within workspace. Try calling with a relative path from the repo root.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not present in tool definitions. Both tools are read-only and idempotent, explicit annotations would help the MCP client and LLM reason about safety and retry logic.