Loading ToolBench
A Model Context Protocol server for SQL optimization powered by PawSQL, supporting multiple database types including MySQL, PostgreSQL, Oracle, and others. Provides tools for SQL analysis, workspace management, and query optimization.
The server defines three tools for SQL optimization and workspace management via Spring AI MCP framework. While tool names follow verb_noun conventions and input schemas are present, the implementation suffers from significant gaps: descriptions lack actionable context, parameter descriptions are minimal or missing, output schemas are undocumented, and error handling is not visible. The server relies on an external PawSQL backend (not shown in source), making it impossible to assess actual error guidance, validation logic, or recovery instructions. Tool definitions appear inferred through Spring's ToolCallbacks mechanism rather than explicit registration, which caps individual tool scores at 50 per HARD SCORING RULES.
Get workspace information by name or ID, including ID, database type, etc. Returns a notification if the workspace is not found.
List current workspaces and return their basic information in a markdown table.
Optimize SQL and return the optimization results in markdown format
Output schemas not documented. No tool returns a documented schema showing what fields are in responses, forcing LLMs to guess at response structure and breaking downstream chaining.
Parameter descriptions are missing or trivial. 'sql' parameter lacks guidance on SQL dialects, query length limits, or expected formats. 'dbInfo' is an object with nested 'dbType' but no explanation of how it differs from the top-level 'dbType' parameter. LLMs cannot infer parameter semantics from names alone.
Tool descriptions lack context for selection and prerequisites. 'List current workspaces and return their basic information in a markdown table' does not explain WHEN to call this (e.g., is it a discovery step before get_workspace_info?), WHAT 'basic information' includes, or WHETHER pagination exists. Baselines show A+ tools average 194 chars; these are 50-150 chars with low semantic density.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Ambiguous parameter naming in 'optimize_sql': 'useWorkspace' is a boolean whose meaning is unclear without reading the description. The description states it should be 'true if user provides DDL info or database connection info', but this is a derived value, not user intent. Should this be inferred from parameters, or should users explicitly pass it? Inconsistent semantics confuse LLMs.
Tool definitions inferred via Spring ToolCallbacks.from(service), not explicitly registered with names and schemas in source. Actual tool registration logic is hidden in Spring AI's reflection/introspection layer, making it impossible to verify if schemas are properly structured, if descriptions match best practices, or if tool metadata is complete.
No error handling guidance visible. Descriptions mention 'Returns a notification if the workspace is not found' (get_workspace_info) but do not explain what 'notification' means, whether it is retryable, or what the LLM should do next. Per pattern:recovery-guide, errors must guide the next action.
Parameter 'dbInfo' is an object with nested schema but no guidance on required fields, conditional dependencies, or valid combinations. Description says 'Do not provide default values if not provided by user. Set to null if user doesn't provide DDL or database connection info', but does not explain what 'database connection info' means (host, port, credentials?) or how credentials are injected securely.
No evidence of input validation or constraint declarations. Parameters like 'sql' and 'workspaceName' are untyped strings with no length limits, regex patterns, or enum constraints. LLMs may pass empty strings, SQL injection payloads, or excessively long queries without feedback.