Loading ToolBench
MCP server that provides tools to query SQL Server databases and retrieve table schemas for natural language to SQL conversion
TalkToDb has 2 tools with critical definition gaps. Tool names lack standard verb prefixes and are hyphenated (non-standard). 'List-Db-Table-Schema' uses hyphens instead of underscores and is awkwardly worded; 'ExecuteSqlQuery' mixes PascalCase with imperative intent. Both tools have minimal descriptions (41 and 99 chars respectively) that lack context for LLM selection, they state WHAT but not WHEN or WHY. Input schemas are present but severely limited: List-Db-Table-Schema has an empty object schema (no parameters), and ExecuteSqlQuery accepts only a bare 'sqlQuery' string with a generic 10-char description. Neither tool documents output schema structure. Error handling is silent (exceptions caught, empty lists or null returned with no recovery guidance). No parameter constraints (enums, ranges), no dependency hints, no idempotent/destructive annotations. The tools are functional database accessors but lack the LLM-optimization and safety guards required for production agent use.
Executes the given SQL Select Statement against the database and returns the result
Lists all the db tables and columns schema
Tool names do not follow verb_noun convention and use non-standard hyphenation. 'List-Db-Table-Schema' should be 'list_database_tables' or 'get_schema'. LLMs expect action verbs at the start; hyphenated names are non-canonical.
Descriptions are too short and generic. 'Lists all the db tables and columns schema' (41 chars) lacks context for when/why an LLM should call it. Should be 50-200 chars explaining purpose, prerequisites, and what structure is returned. E.g. 'Retrieves the complete database schema (tables, columns, data types, nullability). Call this first before running queries to understand available data.'
ExecuteSqlQuery parameter 'sqlQuery' has no type/format constraints. Description is '10 chars: 'SQL SELECT query to execute'. No mention of: forbidden operations (INSERT/UPDATE/DELETE enforced at runtime, not declared), result limit, timeout, or format. LLM cannot validate input before calling.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 28 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 6 | - | v1 |
No output schema documentation. Callers do not know what ExecuteSqlQuery returns. Code shows it returns { Columns: string[], Rows: object[] }, but this is invisible to the LLM. List-Db-Table-Schema returns TableSchema[] but this structure is not documented in the tool definition.
Error handling is silent and non-recoverable. Both tools catch exceptions and return empty results or null without context. LLM receives no guidance: was the schema empty, or did a connection fail? Should retry, or ask the user? Pattern: error-classification demands categorizing errors as retryable/user-fixable/fatal with recovery hints.
No parameter descriptions for ExecuteSqlQuery's 'sqlQuery'. Baseline expects 100% of tool params to have descriptions. 'SQL SELECT query to execute' is too short (10 chars); should specify: minimum/maximum length, disallowed operations (DELETE/INSERT explicit), result row limit, timeout behavior.
No tool annotations (readOnlyHint, idempotentHint, destructiveHint). Both tools are read-only but this is not declared in metadata. LLM cannot infer safety profile without annotations.
No result pagination or limits. ExecuteSqlQuery can return unbounded result sets. If a query matches 10,000 rows, all are returned, blowing the context window. Should enforce max_results (e.g. 100) and return a continuation token or next_cursor.
List-Db-Table-Schema has no input parameters, yet it is tool-registered. This is functionally correct (discovery tools often take no params) but the empty schema '{}' could confuse tooling. If params are optional, document this explicitly.