Loading ToolBench
MCP server for Salesforce/SalesLoft database access via JDBC, providing tools to query tables, retrieve columns, and execute SQL statements
Three tools with mostly clear intent but significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Tool names follow verb_noun pattern well (get_tables, get_columns, run_query). Descriptions are adequate (100-200 chars) and explain what the tools do, but lack critical context about when to use each, dependencies, and what to expect from outputs. Parameters have type definitions but lack detailed descriptions explaining constraints, formats, or valid ranges. No documented output schemas, no pagination support despite tools that could return large result sets, and no error recovery guidance. SQL parameter in run_query lacks format constraints or examples of valid syntax. The server exposes a functional JDBC bridge to Salesloft but misses patterns for result limiting, composition hints, and LLM-friendly error messages.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `salesloft_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 `salesloft_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 schemas not documented. Tools return CSV format but LLMs cannot infer field names, types, or structure. LLMs must guess at output shape, breaking composition and chaining.
salesloft_run_query 'sql' parameter lacks constraint documentation. No mention of valid clauses, quoting rules, SQL dialect specifics, or length limits. Description states 'Identifiers should be quoted using "" characters' and lists valid clauses but provides no examples or validation guidance for LLMs.
No pagination support. Tools accept no limit/offset/page parameters. Large result sets (e.g., thousands of tables or columns) would be returned in full, exhausting context windows and breaking LLM reasoning. Description does not warn about result limits.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 12 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Parameter descriptions minimal or missing. 'catalog' and 'schema' parameters have one-word descriptions ('The catalog name'). No explanation of what they do, when to use them (optional), or how they interact with table/column retrieval. LLMs cannot reason about parameter dependencies.
Error handling lacks recovery guidance. Code throws RuntimeException('ERROR: ' + ex.getMessage()) with no classification (retryable vs. fatal), no actionable next steps, and no enrichment of error context. LLM receives bare exception text and cannot self-correct.
No idempotency guarantees. run_query executes arbitrary SELECT statements. While read-only, no documentation clarifies idempotency or side effects of VIEW materialization, triggers, or logging.
Missing dependency hints in descriptions. No guidance that get_tables should be called before get_columns or run_query. LLMs cannot infer optimal discovery sequence.