Loading ToolBench
A Model Control Protocol server that provides database query tools for multiple database backends including PostgreSQL, MySQL, Snowflake, BigQuery, DuckDB, ClickHouse, and others
The MCP Data Gateway server exposes 4 database query tools with minimal schema documentation and weak descriptions. Tool names are action-oriented (list_, discover_, prepare_, query) but descriptions lack context for when to use each tool and what they return. Most critically, input schemas are either missing or incomplete: list_tables has an empty input object {}; discover_data and prepare_query have basic string parameters with minimal type information; query_data has no visible schema in the provided source. Output schemas are completely undocumented, LLMs cannot plan downstream operations without knowing what fields are returned. No error handling guidance, no parameter constraints (enums, limits), and no idempotency markers for a tool that executes destructive SQL. The server appears to be a code generator output (mcpgenerator/server_raw.go) rather than hand-crafted production code, suggesting schema quality was not prioritized.
Discover data structure for connected database gateway. tables_list parameter is comma separated table to fetch data samples. Discovery better to call with a list of interested tables, since it will load all their samples.
Return list of tables that available for data in database. This is usually first this agent shall call.
Verify query and prepare output structure for query in database. This tool shall be executed before query, to examine output structure and verify that query is correct.
Query data structure for connected database gateway
list_tables and query tools have no visible input schema definitions. list_tables declares empty input {} which satisfies the signature but provides zero validation surface. query_data schema cannot be located in provided source.
All tool descriptions are under 100 characters and lack critical context. 'list_tables' description is vague about what structure is returned and when to call it vs discover_data. 'query' has no description at all in the source (only generic 'Query data structure for connected database gateway').
No output schemas documented for any tool. LLMs cannot reason about downstream tool chains without knowing field names and types returned by list_tables, discover_data, prepare_query, or query. This violates the pattern that every tool must document its return structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 20 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 30 | - | v1 |
The query tool has no SQL injection safeguards documented and no error recovery guidance. Agents executing arbitrary SQL queries need clear guidance on what errors mean and how to recover (e.g., 'Syntax error in query. Call prepare_query() first to validate.').
Parameter descriptions are minimal or missing type context. 'tables_list' in discover_data says 'Comma-separated list of table names to discover' but does not specify character limits, required format, or behavior on invalid table names. prepare_query's 'query' parameter has no validation hints for SQL syntax.
No distinction between read-only operations and data modification tools. All four tools are marked READ_ONLY risk, but prepare_query and query could have side effects (locks, temporary objects) depending on the underlying database. Agents need clear idempotency markers.
No pagination or result limits specified. If discover_data or query returns thousands of rows, the LLM context window could be exhausted.
discover_data's description mentions 'samples' but does not specify how many rows are sampled, what columns are included, or the format of the returned structure. This forces LLMs to call it blindly.