Loading ToolBench
FastAPI-based server providing database query execution and table data access for PostgreSQL databases
This server has severe definition quality gaps. All 17 tools lack parameter descriptions entirely, the schema shows only type and parameter name, with no explanation of what each parameter controls or accepts. Tool descriptions are minimal (10-20 chars), below the 50-200 char baseline for LLM-optimized descriptions. Output schemas are undocumented; responses are raw database rows with no pagination, limits, or field documentation. No error handling guidance, exceptions return raw error strings. The generic fetch_all_from() and fetch_by_id() pattern creates 16 nearly identical tools with no clear differentiation. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. SQL injection risk in fetch_all_from() via f-string table names.
Fetch a specific booking by booking_id
Fetch all bookings from the bookings table
Fetch a specific conversation by message_id
Fetch all conversations from the conversations table
Fetch a specific offering by offering_id
Fetch all offerings from the offerings table
Fetch a specific provider by provider_id
All parameter descriptions missing. Tools like get_user accept 'user_id' with no explanation of format, constraints, or whether it's a UUID, integer, or email. LLMs cannot infer parameter meaning from names alone.
Tool descriptions are 10-20 characters, far below the 50-200 char baseline. 'Fetch a specific user by user_id' provides no context for when to use this vs get_users, what fields are returned, or what happens on not-found.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | 2026-07-28+ | v2 |
Fetch all providers from the providers table
Fetch all service categories from the service_categories table
Fetch a specific service category by category_id
Fetch a specific service offering by service_offering_id
Fetch all service offerings from the service_offerings table
Fetch a specific service type by type_id
Fetch all service types from the service_types table
Fetch a specific user by user_id
Fetch all users from the users table
Execute a SELECT query against the PostgreSQL database
No output schema documentation. Responses return raw database rows (dict(zip(columns, row))) with no field descriptions, types, or pagination info. LLMs cannot plan downstream calls without knowing what fields are available.
SQL injection vulnerability in fetch_all_from(). Table name is interpolated via f-string: f'SELECT * FROM {table}'. An attacker-controlled table parameter could inject arbitrary SQL. Use parameterized queries or a whitelist.
No pagination or result limits. fetch_all_from() returns all rows from a table with no limit, offset, or total count. Large tables will blow context windows and waste tokens. No tool annotations (readOnlyHint) despite all tools being read-only.