Loading ToolBench
MCP server for connecting to Snapchat Ads data via JDBC driver, providing tools to query tables, retrieve columns, and execute SQL statements
Three tools with consistent schema structure and moderate descriptions. All tools have explicit registration with input schemas and basic descriptions. However, descriptions lack depth regarding error cases, dependencies, and guidance for LLM selection. Parameter descriptions are minimal. Output format (CSV) is mentioned but output schema is not formally documented. Error handling is weak, exceptions are caught and rethrown as RuntimeException without actionable recovery guidance. The server follows a simple pattern (discovery → schema inspection → query execution) but lacks the LLM-optimization and completeness expected of A-grade tools.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `{prefix}_get_tables` tool to get a list of available tables. The output of the tool will be returned in CSV format, with the first line containing column headers.
Retrieves a list of objects, entities, collections, etc. (as tables) available in the data source. Use the `{prefix}_get_columns` tool to list available columns on a table. Both `catalog` and `schema` are optional parameters. The output of the tool will be returned in CSV format, with the first line containing column headers.
Execute a SQL SELECT statement.
Output schema not formally documented. Tools return CSV strings but LLMs have no structured schema to parse headers, column types, or result cardinality. CSV parsing is error-prone for LLMs and wastes tokens on format negotiation.
Error handling does not guide recovery. Exceptions are caught, wrapped in a generic RuntimeException with 'ERROR: ' prefix, and rethrown. No categorization (retryable vs user-fixable vs fatal). No suggestions for next steps (e.g., 'Call {prefix}_get_tables to see available tables').
Parameter descriptions are minimal or absent. 'catalog', 'schema', 'table', and 'sql' lack constraints, format specs, or dependency hints. For {prefix}_run_query, 'sql' description mentions valid clauses and quoting rules but does not specify character limits, injection handling, or examples of what SQL dialects are NOT supported.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
{prefix}_run_query description claims SQL dialect is 'mostly based around SQL-92' but does not define what features ARE supported vs which are NOT. LLMs will guess and produce invalid queries. Should enumerate supported clauses explicitly and clarify JOINs, subqueries, CTEs, window functions, etc.
No parameter for result limits. Tools do not document max row counts, pagination, or guidance on breaking large result sets. If Snapchat Ads has millions of rows, LLMs can request unbounded queries that exhaust memory or hang the agent.
Tool descriptions do not specify use-case sequencing. {prefix}_get_tables and {prefix}_get_columns are discovery tools but the description does not say 'Call this FIRST to discover available tables' or 'THEN call {prefix}_get_columns with the table name returned by this tool'. Multi-step workflows need explicit ordering hints.