Loading ToolBench
MCP servers exposing safe, read-only database tooling with LLM-powered NL→SQL translation, plus web search capabilities with integrated LLM responses
This server provides 7 tools across two domains (database SQL execution and web search). Tool definitions are partially complete: all tools have descriptions and input schemas are visible, but quality is inconsistent. Naming is generally acceptable (verb-first: list_, describe_, preview, search_, nl2sql_, nlq_), but descriptions vary from adequate to overly technical. Schemas include parameter types and some descriptions, but lack comprehensive constraints (enums, ranges, formats). Error handling is present in the sanitization logic but not well-integrated into the tool responses themselves. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared. Database tools show security-conscious design (SQL injection prevention via sanitize_sql, allowlist enforcement) but this is implementation detail, not surfaced in tool definitions. Web search tools lack depth, nlq_to_response conflates search with LLM invocation, violating separation of concerns. Output schemas are not documented in the tool definitions.
Return columns + types for a table.
Return list of readable tables.
Convert a natural language question into a SQL query using an LLM, execute the query, and return results with a summary.
Force one Tavily web search, then have the model answer using that context. Avoids relying on tool-calls, and avoids 'role: tool' messages entirely.
Return the first N rows from a table with optional offset.
Returns a string of text from a Tavily web search.
nlq_to_response violates single-responsibility principle, it combines web search + LLM invocation in one tool. This forces users to accept whatever the LLM decides rather than composing search and reasoning separately.
No output schemas documented for any tool. Tool definitions state what inputs are accepted but do not specify what fields/types are returned, forcing LLMs to infer result structure and making chaining difficult.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared. All 7 tools are read-only but this is not surfaced in the MCP protocol, so clients cannot infer which operations are safe to retry.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Execute a read-only SQL SELECT query with result count capping. Queries are sanitized to prevent prompt injection attacks and non-SELECT statements.
nl2sql_query description does not document the output format, whether it includes the query text, raw vs summarized results, or how summary is generated.
search_web and nlq_to_response lack explanation of rate limits, result count caps, or service dependencies. No guidance on retry behavior if Tavily API fails.
sql_query description mentions result capping at 100 rows, but preview defaults to 20 and accepts a limit parameter, inconsistent result limits across similar tools invite misuse.
nl2sql_query and sql_query both execute queries but differ in interface (one adds NL abstraction, one is direct SQL). No description clarifies when to prefer one over the other.
table_hint parameter in nl2sql_query is optional but its purpose and format are not explained. Does it accept a table name, partial match, or SQL expression?