Loading ToolBench
MCP server for connecting to Certinia (Salesforce) and other JDBC-compatible databases via SQL
Server provides 3 read-only SQL-based tools with basic descriptions and JSON schemas. Tool naming follows verb_noun conventions (get_tables, get_columns, run_query) which is appropriate. However, descriptions are inconsistent in depth and quality. Input schemas are present for all tools but lack depth in parameter validation (no enums, format constraints, or min/max bounds). The server returns CSV output which is unstructured and difficult for LLMs to parse reliably. Output schemas are not documented anywhere in the codebase. Error handling is minimal, exceptions are caught but wrapped in generic RuntimeException without actionable recovery guidance. Parameter descriptions are adequate but lack format specifications and expected value ranges. Overall, the tools are functional but fall short of production-grade quality due to weak output structuring and error messaging.
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 documented. All three tools return CSV output, but there is no specification of which fields will appear, their types, or their order. LLMs cannot plan downstream tool calls or extract structured data reliably from unstructured CSV.
CSV output format is error-prone for LLM parsing. No structured JSON response. CSV can contain commas, quotes, and newlines in data which confuse naive parsing. Returning McpSchema.TextContent with CSV violates the pattern of structured tool output, should return McpSchema.ToolResult with typed fields.
run_query tool description is vague and lacks critical constraints. Description says 'Execute a SQL SELECT statement' but does not specify: What SQL syntax is allowed? What tables are accessible? What joins are safe? What's the result row limit? The long description mentions 'Valid clauses: FROM, INNER JOIN, LEFT JOIN, GROUP BY, ORDER BY, LIMIT/OFFSET' but this is a long string buried in the description, should be in parameter validation or quoted output constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
No input validation or error guidance. GetColumnsTool.run() catches exceptions and rethrows as generic RuntimeException('ERROR: ' + ex.getMessage()). An LLM has no idea whether the error is retryable, requires a different table name, or is unrecoverable. Error should categorize and guide recovery (e.g., 'Table not found. Call {prefix}_get_tables to see available tables.').
Parameters lack format constraints and ranges. 'sql' parameter in run_query has no format specification, length limit, or explicit statement of allowed SQL features. 'table' parameter in get_columns is required but has no length/character set constraint. Without enums or pattern declarations, LLMs may pass invalid values and waste retry cycles.
No pagination support. Tools return entire result sets in CSV. If a table has thousands of rows, get_tables or get_columns will bloat the response, exhausting context window. No limit/offset or page_size parameter.
Missing metadata in responses needed for tool chaining. If get_tables returns a table name, the agent needs to pass that exact name to get_columns. If table names contain spaces or special characters, the CSV output must be clear about quoting. Similarly, get_columns should return the exact column names the agent needs for run_query SQL construction.