Loading ToolBench
MCP server for enterprise document processing and RAG retrieval, exposing tools for hybrid vector search, SQL queries, and log reading
Server has 8 tools with clear naming (verb_noun pattern) and reasonable descriptions (100-250 chars). However, input schemas are partially visible but lack complete type definitions and constraints. Parameters like 'sql' and 'query' have descriptions but no format/length constraints. Output schemas are not documented. Error handling guidance is minimal. Tool composition is sound (each does one thing), but parameter validation rules and recovery guidance are absent.
Return column name, type, and nullability for one table in the public schema.
Answer a question from the company's documents (the knowledge base). Use this for any unstructured/knowledge question — policies, docs, how-tos, definitions. It runs a grounded multi-agent retrieval pipeline that cites its sources. Do NOT use it for structured/numeric data in the SQL database (use the SQL tools) or for changing data (use sql_execute).
List available log files.
List all tables in the public schema of the Postgres database.
Perform hybrid vector search (dense + sparse) against the knowledge base in Qdrant. Returns relevant document chunks with scores.
Read log entries from a specified log file.
SQL tools (sql_query, sql_execute) lack input validation constraints. No documented limits on query complexity, result row count, or execution timeout. LLMs can pass arbitrarily large queries or expensive operations.
Output schemas not documented for any tool. LLMs cannot infer what fields to expect (e.g., does sql_query return {rows: [...], count: int} or {data: [...], total: int}?). Breaks downstream tool chaining.
Error handling guidance absent. Tools return errors but do not guide LLM recovery (e.g., 'table not found' should suggest list_tables; 'invalid SQL' should explain syntax rules).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Execute a write statement (UPDATE or DELETE) against the Postgres database. This tool is gated by human-in-the-loop approval — the graph pauses at this tool call so a human must approve before the write runs. Returns the number of affected rows.
Execute a read-only SQL SELECT query against the Postgres database. Returns up to row_limit rows as dictionaries.
read_logs and sql_query lack pagination/limit enforcement. No documented max row count or result size cap. Large log files or result sets can exhaust context window.
sql_execute description mentions 'human-in-the-loop approval' but no tool parameter or mechanism visible to request/confirm before execution. Confirmation pattern not implemented.